Client Case: 8 Factors That Boosted Our Agile Transformation Success
8 min read
Many teams are currently changing their working approach. Hybrid and distributed working cause challenges for culture and collaboration. Changes and uncertainty call for strategic and organizational agility. Customer focus and innovation demand new approaches to how we work. And we need to modernize how we hire, lead and engage people.
Adopting new work approaches in a start-up is often doable because people already have a growth mindset. But what if you are in a larger or more traditional organization? How do you connect the changes with the business strategy? And how do you mobilize the workforce to make and embrace big changes?
I have recently had to handle these challenges as a transformation lead coach in a large European telecom company. Here I will share how we handled it, with very positive results.
The challenges we faced
The challenges we faced were typical for a beginning phase where the transformation wasn’t yet well organized. The focus, roles, and activities were fairly ad-hoc. “Change” was not yet part of the mindset. I will elaborate the most important challenges so that you can be alert on similar situations in your own environment.
A weak connection to the strategy
The new way of working that we wanted to introduce was in a large division of a Dutch telecom business. The context was quite political, and it affected the involvement of the 5 VPs. There was hardly any connection with the strategy. Each VP was responsible for a functional department, without any product or customer ownership. Clear strategic objectives were not articulated. Whenever VPs and directors showed up in Agile discussions, we often listened to helicopter views.
An unstructured approach to agile adoption
Due to the above point, a few small groups of VPs and directors had shaped 3 agile transformation squads that each focused on an agile Way of Working area. These squads had rather slow progress because of fragmented activities and the high focus on reporting rather than doing. What was worse is that contributors came and went, and when present they were literally all over the place. It was caused by a lack of roles and ownerships.
Being too busy with the BAU deliverables
A second complication was that we needed to combine software and hardware development. Team collaboration and processes to handle this were weak. This caused a constant need to work in reactive mode to handle the business-as-usual deliverables. Many teams were well aware that we needed improvements. High time pressure on deliverables made it unfortunately difficult to actively contribute.
A sole focus on processes
One obvious need for improvement was clear, the need for higher predictability. This was clear because many customers complained about it. As a result, a customer-facing team decided to create a cadence model to synchronize the many handovers that were often causing delays. This by itself was a smart decision because it focused on eliminating root causes. But this only changed the process. We needed more holistic changes that include culture and leadership.
Half-baked agile
When I started my job as the lead coach, I wanted to first understand the objectives and what was happening on the floor in relation to those objectives. I heard the good news that some teams were already using Scrum sprints. Unfortunately, the sprints appeared to be artificial timeboxes, and dates were often moved, which is a big no-no in Scrum. What was worse is that the agile culture was missing. Empowerment, information sharing, transparency, trust. It was hard to sense.
The revised transformation approach
After a period of moderate progress, an important pivot happened. One VP started to sponsor the agile transformation actively. And this time around, not just with money and a helicopter view. He became involved as an active participant. It opened up the possibility to review the agile transformation approach. As a lead coach, I had the opportunity to lead that effort.
These are the key elements that helped to move strong and get real results.
1. Target the outcomes
2. Define ownerships and claim investment of effort
3. Set up a central Transformation Backlog for a holistic and transparent view
4. Use themes to keep track of the big picture
5. Empower Change Squads to develop the change
6. Plan in waves and use a Calendar of Outcomes
7. Include the culture side
8. Start early with learning agile skills
1. Target the outcomes
In order to create a shared purpose and motivate the troops, we needed targets. Why do we do this transformation? It cannot be because we want to tick off a checkbox so that we can claim to be Agile.
We decided to conduct a strategy workshop with senior management. Many details of what we wanted to achieve became clear for the first time. We captured the results visually so that we could communicate this vision.
In our case, we used a quadrant with importance and time on the axes and positioned all objectives. This served us well for setting a shared purpose and mobilizing the troops.
2. Define ownerships and claim investment of effort
We needed to solve the problem that the wrong people were driving the change and that virtually no one from the floor was involved in the changes.
We split the roles into three groups: sponsors/stakeholders, transformation owners, and change squads. This made it very clear who finances/sets targets/reviews versus who defines/prioritizes versus who executes respectively. I will explain some of the roles in more detail below.
We also made the role of senior management clear. They are our sponsors and stakeholders. They finance, influence and review. They do not prioritize or manage changes.This change alone gave a huge improvement. Now it became possible to use people’s time in the places where they were adding value. Meetings all of a sudden became so much more dynamic and effective.
For all contributors, we needed a portion of their work week to be allocated to this transformation. This was not only a question of planning. It was mindset also. Ultimately, we wanted people to realize themselves that making changes should be continuous. It should be part of your daily job to nourish that.
To get started it was useful to explicitly reserve that time. The meetings we set up on a weekly basis also helped to create a rhythm of activities.
3. Set up a central Transformation Backlog for a holistic and transparent view
We set up a central Transformation Backlog to rank and plan all transformation work. A single backlog across all transformation areas gave us a holistic view.
As in standard Scrum, we introduced a Transformation Product Owner role for the ownership of this backlog. Two hands-on directors who had a thorough understanding of needs, pain points, and causes took this role.
The backlog starts with big epic-level capabilities and challenges. Zero-impact dependency handling is a capability that was important at the start so that we could improve predictability. A challenge/constraint was unpredictable deliverables by third parties.
Priorities are based on strategic objectives, value, the severity of constraints, and dependencies. We groom and split these into small changes that we then develop in small increments. This helps to make tangible progress that we could get early feedback on.
4. Use themes to keep track of the big picture
When you start with Agile adoption, the choices of what you could focus on may be overwhelming. Of course, you can use the Agile approach and focus on value, but what is the highest value for the organization at this moment? Using themes is a huge help in this case. Elaborated from the Jeff Patton’s story maps, I suggest you define themes first. You basically build a grid of themes and change areas.
Themes could include things such as: mature the backbone, deliver combined hardware/software releases, reduce batch size of product changes. Themes are things you invest in for a time period to come and are often linked with outcomes. Focusing on one or two themes per wave of work helps the focus.
5. Empower Change Squads to develop the change
The biggest reinvention in the transformation approach at my client was the introduction of "Change Squads". The idea was that we wanted to empower people. We wanted changes to be developed by the people who were actually going to live with the change.
Not only do they often have the best expertise to implement the change. They know the situation so it helps us work reality-based. And, embracing and sustaining the change becomes more natural as well. What I also like about this empowerment is that it helps to foster an Agile culture from the start.
A Change Squad is generally a long-lived team. Each Change Squad consists of 3-7 people, and they all need to be value-adding. How to compose the squads depends on the content of the backlog. To ensure an outcome-focused effort, I’ve seen the best results if a squad is focused on complete capability or challenge with end-to-end accountability.
For example, you could have a squad that focuses on new product development. That squad covers both the definition and delivery of MVPs, customer interaction, analytics, and market predictions. It also means the squad may need members from different disciplines.
6. Plan in waves and use a Calendar of Outcomes
The Change Squads receive their next work items from the central Transformation Backlog. We started to plan the squad work in 3-month waves, program increments. This was good to get everybody aligned in this new program, clarify vision, and define the next state where we want to be. We kicked off those increments with a SAFe-style PI Planning event.
Of course, you can also plan and execute using a Kanban pipeline without timeboxes as shown in the diagram. This is more lightweight and works well if you don’t have many cross-squad dependencies. You save the overhead of big planning events and synchronization.
One thing that I found useful from the stakeholder perspective is what we called “Calendar of outcomes”. It contained a list of business-level improvements that we achieve. For example, we improve predictability by 30% after implementing changes x and y. Pinning outcomes to dates may sound a bit anti-Agile but it served in our case as a compass and motivator.
7. Include the culture side
The foundation of an Agile WoW is a mindset rather than a framework or practices. Before starting with any technical changes or skill building, think about what you want to accomplish with your culture. What is your current culture and where do you want to go?
We therefore planned focused work on culture right after building the Agile backbone. Because culture-shifting takes time because it involves an assessment of your current state and a designed set of behavior changes. By starting early, you can support all other changes with the new behaviors.
8. Start early with learning agile skills
Learning Agile skills serves several purposes. Most importantly, learning helps to mobilize the workforce. The more people know about Agile, the more you can empower them in the change process.
Learning also helps to create a different mindset and team culture. We are not just talking about the hard skills here. Learning about new forms of leadership, collaboration, change management, and other power skills really opens your mind about how work can be done differently.
Finally, learning facilitates the roll-out of changes because people will be better equipped to adopt the new way of working. When you develop changes to build new capabilities, think therefore also about the skills and behaviors that people need in order to embrace the change.
Takeaway
Thank you for reading. I have encountered the above-mentioned challenges in more than one mid-size and large-size organization, especially when starting without any facilitation. I suggest taking away the recommendations as lessons learned and adapting them for your context and size, the Agile way! I am keen to hear your experiences or additional ideas, so please feel free to share them in the comments.
