The Agile transformation of T-Mobile CZ and Slovak Telekom began in 2021. This was a big deal from the operator’s perspective, as there was lack of internal experience. At the board level, support from an international consultancy was needed, but it was hands-on support with the design and with the rollout of Tribes that we were a part of.
Everything was new to most people at T-Mobile – Agile thinking, concepts (Tribes, Squads), methodology (Scrum, OKRs). There was a need to provide someone to help virtually flip the traditional organization into this new world that would be “faster”, “better” and “more successful”.
At the beginning of the cooperation (autumn 2021), three pilot Lighthouse Tribes were defined. The key was size. Pay as you go (PAYG) – Tribe, which had had cross-functional teams for some time and Agility was the next logical step, TV CZ and TV SK because these were parts of the company that had well defined product boundaries.
The collaboration ran from autumn 2021 until December 2022, we are currently continuing to coach and ad-hoc mentor leaders. In total, the collaboration involved over 100 people. This case study describes our work in the PAYG Tribe.
PAYG Tribe
The products of Pay as you go or PAYG Tribe are prepaid cards, which the Tribe is developing both business-wise and technologically (specifically T-Mobile Twist and other brands such as Kaktus, Mobil.cz, etc.). The transformation involved a total of 25 people who were divided into 4 squads during the design. The Tribe Leader for this Tribe is Andrea Kilingerová, who also worked with us to create this case study.
How did our cooperation start?
A series of meetings was held in the autumn of 2021 to define and design the new Tribes according to one of the scaling models, the so-called Spotify model, chosen by the client. The transformation of the entire company was primarily managed by an international consultancy, and we were in charge of the design and launch of said Tribes.
We implemented joint meetings with the Tribe and Tech Leads and internal coaches twice a week, where we went into the necessary detail and handled the items of the Tribe transformation backlog defined by us in an agile way. The backlog included topics such as Agile planning at the Tribe level, what are OKRs and how they differ from KPIs, how to make a Tribe card and Tribe memo (basic description of Tribe – purpose, organizational divisions, key roles, goals in the form of OKRs for the year and quarter).
“No one at T-Mobile had previous hands-on experience with Agile management. The Agile way of working within IT, based on the SAFe methodology, which had worked in the company up to that point, was not an ideal model and was a rather unreadable organism for business people,” says Tribe lead PAYG, Andrea Kilingerová
What exactly did we do in Tribes?
First we defined the purpose and goal of Tribes, then the structure (Squads), the necessary roles and competences (Squad members, Chapters). We then did interviews for the key role of PO, which we attended and provided an outsider’s perspective and an Agile expert’s view of the candidate’s suitability.
“In recruiting for me, your role was again quite crucial as the mostly internal candidates knew each other, the opinion of a person outside the perimeter was very valuable. I can also think of Roman facilitating meetings with real live 3D people who work in Agile and have survived the transformation of their companies. Thanks for that! It was very encouraging!” Andrea adds.
Furthermore, together with our internal Agile coach Lukáš, we prepared an Agile Bootcamp at the beginning of January. The official launch of Lighthouse Tribes took place there. Since COVID was in full force at that time, everything was done online. The goal of the Bootcamp was:
- To learn in an experiential way what Agile is and specifically the SCRUM framework.
- Define the Squad card – i.e. the identity of the Squad (team), why we exist, what our goals are, and agree on how to work together (communication channels, regular meetings, working with JIRA).
- Present the steps for the following week and the overall scheme of the first quarter.
It was agreed with the Board that Q1/2022 would be a pilot and a starting point, with the aim that everything would “settle” into the new way of working and thus they did not expect to meet ambitious targets or deliverables. However, meeting annual corporate KPIs was expected. The main aim was that clients would not feel negatively that any transformation was taking place internally. After this decision and transparent communication to the company, everyone was visibly relieved.
What was our role and what were the biggest challenges we had to deal with?
The role of RainFellows was to support mainly Andrejka (Tribe Lead PAYG), Pavel (Tribe Tech Lead PAYG) and Lukas (internal AC for PAYG). The goal was to have not only a Tribe where delivery works at the end of Q1, but also leaders firmly settled into their roles and independent of RainFellows/Roman. Beyond the joint meetings, the support for the leaders consisted primarily of regular 1on1 meetings where we discussed topics related to their role performance through mentoring and provided answers to their questions, such as dealing with specific situations or supplying missing know-how. Later, mentoring turned into coaching on topics that the leaders themselves brought up.
The biggest challenge we faced during the design phase was the End-to-End (E2E) composition of Tribe. The pressure was to keep only PAYG business competencies and leave IT/delivery to other Tribes. But what’s Agile about that? Our priority was to get as close as possible to the ideal of autonomous, E2E Squads. This eventually proved to be essential to reducing Time-to-market, ensuring the necessary deliveries and a good feeling among Tribe folks that they were finally in control of important decisions. We set a value of less than 45 days as a big improvement on standard delivery. By taking incremental steps, we achieved a significantly better figure of 33 days in the first quarter itself.
“RainFellows has continuously given us confidence and determination in some important decisions. At the moment when you are starting from scratch, building Tribe, a complex ecosystem of business and technology people with high expectations, you feel a huge responsibility”, Pavel mentions.
The challenge was not only to assemble an E2E functioning team, but also that Lighthouse Tribe had to find a way to continue to support existing delivery from the still valid and in-progress roadmap of projects. In such a “dual” mode, communication, quick decision making, and most importantly, experience in complex transformations is important.
From the beginning, it was evident how important the collaboration between business and technology was. When designing our Pay as you go Tribe, we focused mainly on E2E delivery capability. Therefore, we relied on a simulation roadmap, which was prepared by appropriately selected business representatives and enriched with expert estimates by colleagues from technology. This simulated list of the most important and most frequently needed roles and systems was our guide for defining variants of the required competency definitions.
“It is always an advantage to have people who can speak the language of business and technology. This RainFellows “putty”, charged with Roman’s energy and unbeatable streams of laughter, helped keep the mood up even at moments when it was uncertain whether the proposed design would work. Deeper IT knowledge proved an advantage when debugging technological processes on existing, often still monolithic systems. The big challenge is to find a form of agile collaboration between development teams in different tribes over one such system. Finding a partner that understands the benefits of cloud-native microservices for our convoluted environment was also key to finding a suitable way to deploy Tribe’s design into reality.”, Pavel adds.
As shown in the next steps of the transformation, dependencies during planning lead to increased complexity at the central QBR process level. This then places demands on a “fair” prioritization system and reliable estimates. Central Tribes, supplying for many others, simply become the site of necessary prioritization with increased complexity, as does the entire QBR process. In contrast, in our Tribe, prioritization and estimation was significantly easier. Essentially, it was a brainstorming session over two supporting questions:
- What do we need to do to meet our OKRs?
- Can we do it in 3 months with our capacity?
Anything that can be discussed within the Squad or Tribe is easier. No need to invent a universal key for prioritization and estimation across the company.
Not all dependencies were cut during design. In large companies, Tribe is rarely completely independent of its environment. There remained a few critical dependencies on central tribes that implement any changes to systems whose modifications could not be distributed to the tribes. To avoid conflicts in priorities it was important to agree on a long-term strategy (Tribe independence) and how to ensure current quality (Central Tribes). The agreed process was a result of those joint negotiations.
What were the results?
The intensive collaboration took place between October 2021 and September 2022. As usual, we expected a negative Tribe eNPS a few months after such a major change. But it turned out to be not only positive but also quite high. The first measurement at the end of Q1 showed a value of 16, the following quarter we were at 32 and at the end of Q3 we reached a value of 55.
“This is one of the best things that has happened to me in the last X years at TMOB”, says one of the members of the PAYG Tribe
After this period, the aforementioned mentoring and coaching of Tribe leaders continued until the end of 2022. After some minor deflections caused by the next wave of Agile Transformation, we even reached a Time-to-market (TTM) of 22 during Q4, which significantly exceeded the original plan.
What's next for PAYG T-Mobile?
Two Squads out of four in PAYG are established and are working according to SCRUM without major problems. The two BAU (Business As Usual) dominated Squads were switched to Kanban after the first quarter as planned. For one this new way of working has sat well, for the other we need to redefine the items that are tracked in Kanban and have all work visible in one place.
At the strategic planning (QBR) level, collaboration is not getting stuck fundamentally, the exception being estimates and overloading one central Tribe – see the challenges paragraph above.
It is now important for the whole Tribe to define its strategy, but this is not directly related to the implementation of Agility.
Experience through the eyes of leaders
We discussed the whole transformation with Andrea and Pavel in detail in our Agile Talks show on Red Button EDU. Listen to what worked very well from their point of view during the transformation, what worked well for them and what they recommend to do differently.
Get in touch with us!
Did you find this transformation and the way we work interesting? Would you like to see if we could help your company too?
Get in touch, I’d be happy to discuss the details with you in a non-binding chat and see how we could help you too.
