From zero to Agile to agility

Home » Articles » The Travel Guide » Travel Reports » From zero to Agile to agility

… how we switched from local improvements to a new structure

This is a story of our Agile Transformation where we transformed our enterprise. The leadership team of a sub-unit consisting of 2.000 people of our company sat together, discussing how to improve.

We sat there, wondering. And the insight came, that driving improvements in each subunit would not get us further. We rather needed to look across! We as leaders were too far away from the action. We could not find the needed cross-organizational improvements ourselves, but rather needed to involve people from across the whole organization.

Preparing the change: experiments, simulations, and co-evolution

In 2008, the leadership team of a large sub-unit of our company sat together, discussing how to improve. The unit consisted of 2000 people distributed over 7 countries across Europe, India and China. It was organized in a Project Office, an Architecture & Technology unit, several development units, a SW integration and testing unit and a Product introduction unit. Driving improvement was nothing new for us. For more than a decade we had continuous focus on this, driving improvement program after improvement program. But we felt stuck. Each unit had improved its processes over many years and was running out of ideas. Yet, we were not happy with our status-quo: some problems remained despite all our efforts. For example, our projects still faced a lot of delays, affecting our RoI, there was a constant debate between product management and the development organization (“Why are you delivering late? You are so unreliable!” vs “You are all the time changing requirements!”). Quality had improved over the years, but still we were away from where we wanted to be. And the product uptake after a SW release wasn’t as fast as we were hoping (“Where is the promised hockey stick?”).

Do not walk alone

So, we sat there, wondering. And the insight came, that driving improvements in each subunit would not get us further. We rather needed to look across! As we were in the mood of “brutal honesty”, we also saw, that we as leaders are too far away from the action. We could not find the needed cross-organizational improvements ourselves, but rather needed to involve people from across the whole organization.

So, we set up several workstreams, each dealing with a problem domain, like, for example, “How could we plan better?”. And we invited people from each subunit to the workstreams to look holistically at the challenges we faced. That invitation was communicated in an All-employee-meeting. And over the course of two months, we got about 140 people who were passionate to – in parallel to their daily work – contribute to a workstream.

Open up for insights

There were a lot of important discoveries in the workstreams. We integrated the findings in the leadership team. And we used frequent All-employee meetings and unit meetings to communicate where we were. That initially felt like a daring step: communicating half-baked concepts and ideas. But sharing them and showing the vulnerability and say “This is what we found so far and what we think right now – any further ideas or proposals?” reassured people across the whole organization, that they can contribute and share their ideas. And by that in increased the trust in our leadership team.

Driving the workstreams and integrating, communicating, and discussing the findings took a lot of effort from the members of the leadership team. So, we made another important step: we really wanted a significant change to happen and gave it priority. Normally, we would work 80% of our time on operational issues and maybe 20% on people, process, and organizational questions. Now we decided to turn it around: we spent 80% of our time on the improvement work and 20% on operations. For example, working with the project managers changed from monthly steering group meetings and weekly reporting to short, weekly “make it happen meetings” as we called them. That felt very strange in the beginning. But soon we learnt, that turning the 80/20 around worked well: our project managers did not need us as much as we thought. Project execution progressed in the usual way. A first impression of the “illusion of control” phenomenon – a term I learnt about later-on.

Stop planning, start trying

After about 4 months, the workstreams had produced 500 slides of new process descriptions. What a productivity! But when we realized it and thought about that in the leadership team, we said: this needs to stop! Because we had discovered some important things: (a) When we ask people and involve them, we find a lot of volunteers – people are passionate about the success of our organization! And (b) people are clever! When we involve them and make them think together in cross-functional teams, they can figure out things by themselves. So, the good old straight-jacket of process descriptions was not helpful any more as its speed of improvement was slow due to the centralization (everybody uses the same process and deviations from the process need to be approved. Process improvements could take 1 year to materialize).

But what could we do instead? Some of us had heard about a thing called “Agile”. I had a look at it and I thought “This can not work on a large organization!” Well – it was 2009 by that time and there were no good scaling examples. But in the workstream dealing with SW development they said they would like to try out Scrum. And of course, we let them do it!
So, a team got training, tried it out and came back telling us how great it was. And they are the experts, and we need to listen to them!

Start small and scale

So that way, in Scrum we found a minimal, decentralized, and flexible process framework. But we still needed to understand how to scale. Luckily, the other workstreams had done some good work: We had an idea how to plan on large scale with a long-term view (24 months) staying flexible and adaptive. So the question was, how we could combine that with the Scrum short-term (2-3 months) perspective. That was easier to figure out than we had thought: within one workshop we had an idea how to handle our development portfolio on the high level mid-long-term perspective and combine it with the Scrum framework’s low-level short-term perspective.

From silos to empowered teams at scale

In parallel to this, we thought about the organizational structure. We had learnt that cross-functional teams were really good. That implied, that the old, siloed unit structure wasn’t suitable. So, we wanted a structure, that clearly empowered the teams. To emphasize this, we thought about a visualization, that put the teams into the center and all “supporting, service and enabling functions”, like managers, Financial control, HR etc. into the periphery. That circle picture was the base blueprint for our new Development Centers. On top of this, for scaling, we needed an orchestration function, which we called Portfolio and Technology Management. That unit was acting like the “Chief Product Owner” of the organization: managing the high-level backlog (on feature level) and the “long-range-radar”, that we needed to play scenarios to determine what we can say when a customer wants something towards a certain deadline. Though this unit was a central unit, planning was decentralized: The central unit owned the top-level feature backlog, there was a Portfolio Management function in each Development center, managing that center’s feature and epic backlog. And then the Product Owners working with the teams owning one feature with all the related user stories. The central portfolio management was set up as a cross-functional team to have symmetry with the teams in the development centers. And it was purposefully understaffed to avoid, that it starts taking care of too much lower-level work, stealing the empowerment from the teams.

Co-evolution towards the Agile organization

After 9 months into this journey of co-evolution and discovery, we had a stable idea what steps to take: we knew how the teams could work, we knew how to scale in a light-weight manner, and we had an organizational structure idea supporting decentralization and empowerment of everybody in the organization. And to shift from the start-stop mode of projects to a continuous delivery via programs we planned to create an operational program structure.
We created a communication strategy, anchored the whole setup with our people, the unions and works councils. Almost all management positions were opened, and new managers were recruited. Recruitment criterion was not only the operational and management skills, but also an agile attitude.
And we had a transition strategy: we would run the ongoing projects in the old way and as people became available out of these, we would train them in agile ways of working and let them work on the continuously running program.

With that preparation, on the 1^st of January 2010 we “flipped the switch”: the birth date of our agile organization.

Executing the change: learning to walk, then run, then fly

So on the 1^st of January 2010 we had a lot of managers in their new roles, who knew the blueprints and concepts. But of course, now we needed to bring this to real life.

The BIG coach camp

So the leadership teams worked on their local implementation of the concept. And to be able to onboard the teams, we needed strong agile coaches and trainers. With the help of a consulting firm we organized a three-month Coach Camp, where to-be-coaches from all sites were flying in, got intense training and coaching to become coaches and trainers themselves.

After three months they flew back to their home organizations. You can imagine, that being away from home for three months and being together with foreigners in an intense learning and growth experience, created strong bonds between these coaches. After their return they continued to stay connected, exchanging their experiences and advising each other.

Implementing throughout 7 countries

The coaches became members of the local leadership teams, that were now temporarily formed as “Local Transition Teams”. These sorted out a million questions arising from the practical implementation of the concept. The Local transition team leaders, in fact the development site managers were part of the Units leadership team. We had almost daily interactions and monthly leadership team meetings to share our findings and challenges and align on how we would go about resolving them. Once per quarter, the top leadership team had a two-day off-site retrospective, where we intensely discussed all the emerging phenomena of the change. Out of these meetings we strengthened our alignment across the 2000 people organization.

It was an intense time. But also extremely energizing. It was a pleasure to discover all the issues and getting an experience on how easy it is to resolve them when we just work and think together. Continuous improvement became a habit. Everything was transparent and everybody was open to try things, ask for help and help others.

On track with changing the culture

Half-way through 2010 we had progressed well onboarding teams to the agile way of working. Our strategy to empower the teams was working out well and as the teams had this new and liberating experience of being trusted, having the freedom to sort out how they want to work and getting the support needed, their motivation raised. People, who still worked in the old projects became jealous and we got the requests “Can’t I have my agile training earlier?”. From responses like these we could see that we were in track with changing the culture.

Initially, the productivity of the teams was not particularly good. For example, a first feature, where we tried out the new way of working, was implemented by a full 8 people Scrum team over 3 sprints/9 weeks. That same feature could have been done by two experienced developers in the same timeframe. But the learning was the important point and team velocity improved significantly over just 10 sprints. Plus, we learnt how to slice the scope in a more effective way.

By the end of 2010, all teams were working agile and the classic projects were finished.

Will this ever end?

The journey was intense and the phase in 2010 was especially challenging. Many phenomena emerged out of the organization, that needed to be taken care of.

Some challenges:

What to do with the Portfolio & Technology unit

Dissolving the old stove pipe organization and special functions and instead create fully empowered, cross functional teams implied also, that the System Architecture & Technology unit was removed, and the Architects and technical experts moved into the development centers and into the cross-functional teams. Only a handful technical experts were kept in the small central Portfolio & Technology unit for the technical side of scenario work. Our plan was, that the “long-range-radar” work should be orchestrated by the central unit but needed investigations should be done involving the experts in the cross-functional teams. One year into the journey we saw that that was not an optimal setup: The experts and System Architects were fully absorbed by the teams, leaving no time to work in investigations. The team’s 3-month perspective was creating an urgency and mostly won over the needs for a longer scenario perspective. So we were at risk to lose our long-range-radar and by this being less able to respond to our customer’s need to know when we can deliver a function. (Our customers needed to plan on their side as they needed to integrate our SW in their larger multi-vendor SW eco-system.)
We discussed this over several retrospectives and finally decided that we need to change the change: we re-centralized a sufficient amount of System experts and architects and we initiated an upskilling program to build more Experts and Architects closer to the teams. That resolved the problem.

Local changes > a central framework

In order to facilitate cross-organizational learning, we initially created a central “Frameworks” organization. That organization consisted of members from the different sites and their mission was to document the emerging way of working found by the teams and spread good practices. Our thinking was, that if every team and every development center is doing things differently, we would risk to not be able to collaborate across the large organization – reducing our ability to be flexible and adapt as a whole organization.
That team started with good spirit and intentions. But after half a year we started to face a challenge: there was growing friction between this central team and the Local Transition Teams. What was happening? Our top leader tried to intervene. Get people to collaborate. But without success. Eventually after 1 ½ years, that organization was removed – with a bad taste in our mouth. The idea had been good, the people were motivated, but we couldn’t get rid of the friction this created. Looking back from a distance it is quite clear what had happened: We had implemented two mechanisms to align and spread good practices: The central framework unit. And in parallel, the Local Transition Teams, who were fully empowered and who – thriving on that empowerment – were really determined to live the culture of transparency, sharing, and thinking together. Mechanisms for that were in place in the form of the coaches network and the frequent retrospectives on organizational level. The attempt by the frameworks organization to document the emerging practices, was interpreted as an attempt to impose processes again. The bad experiences with that straight-jacket of defined processes from our previous setup was so alive and the desire to escape from it so internalized by the new leaders, that a constructive conversation was not possible. Resolving the unit was the right thing to do.

The tricky balance of autonomy and alignment

A few weeks into the new setup, we had a first Scrum team working on a feature. Our pilot. To learn from that pilot, a number of people from different roles were on-site to observe. The team was ignited. A strong passion for the new ways of working. Working with Scrum. Not only feeling the empowerment, but also encouraged to demand it. One of our Expert System Architects was on site as well. And he had an increasing problem with how the team approached the system architecture. In the preparation phase of the transition, we had discussed how to work with System Architecture. And as we felt that this knowledge and skill is not widely available, we had decided to start into the new setup keeping the review committees for System Architecture. And then see how we can evolve it.
But now, with this pilot team, the empowerment drive was very strong: the team said, “we can do architecture” and they created and started to implement what they thought a good architectural enhancement would be. Our Expert saw this and he saw that the team’s architecture was not good and will lead to expensive technical debt along the road. But the team ignored him and didn’t want to involve the committee. The belief was: “We are agile! We are empowered! Central functions are bad! We can do this!”
Who is right? This is one of the typical management challenges in the beginning of a transition: Intervene because an expert says, “this will not work”? Or allow to team to learn it the hard way? Or might the team be able to do it? How long should we wait?
It is a tricky balance. In this case the decision was, to stress, that “empowerment is there, but within boundaries”. And while it is good to start with as few boundaries as possible, we had just discovered one case, where we needed a boundary: Screwing up System Architecture is expensive. The arising technical debt from a bad architecture can not be resolved easily in many cases and the efficiency and flow for other teams working on the same product is negatively impacted.
So we needed to enforce the committee checks as we didn’t have any better way to avoid the technical debt. But at the same time, we thought: how could we do this more agile? And our approach was, that we (a) made the committees larger, building up new members and (b) asked them to change the way they work: instead of letting teams work on an architecture proposal for several sprints and then review it just to find out that some essential things were wrong, there should be frequent check-ins with the teams to mentor them towards a good architecture proposal.

The transformation is never over

There were many more such challenges, especially in the first year. But over the first two years they became less and less.
Had we finished the transformation?

We definitely had finished the transition – our initial effort to implement the new organizational structure, the new practices, continuous learning, even the cultural evolution.

But as we saw, the transformation is never over.

That insight dawned as we evolved, and as changes happened in our environment. For example, new leaders were appointed. Competent people, who hadn’t been through the journey. And then wondering what we were doing. So discussions, that felt like “we have been here before 3-4 years ago” happened. “Groundhog day”. It felt like a disturbance and binding energy and sometimes frustrating people who had – after all we had been through – to argue for the setup we had and that had proven itself.

And also, in our business things changed over the years. Our product matured more and more. New technology evolved. New customers with their particular needs. Customers doing their agile transformation and asking us to work together with them in a different way. So, we needed to adapt again and again. Our structures. Our ways of working. Our flows. Our boundaries. Our business models. And that adaptation has become a daily business:

An effect, that we could see was, that the initial phase was extremely exciting. Enjoying the change journey, experiencing how our culture evolved to something much better than before. Employee surveys showed better and better results. But then, the ratings went down again. Were we about to fail? The effect we saw is typical for an agile transition: the initial excitement of everything being new is slowly replaced by more and more routine in executing in an agile way. Once people experience the new setup as “normal”, the survey ratings go back to “normal” as well.
We were still learning and adapting continuously. A deeply embedded improvement culture was in place. The adaptation focus had shifted from internal (how do we adapt the organization to agility?) to adapting to external factors (How can we adapt to customer and market needs?)

So, the insight is, that it is not a time-bound transformation. After the initial transition, there is – if you succeed – a continuous evolution going on. Change is the new normal. Just the initial excitement is gone. Replaced by the excitement of innovation – as now the organization is set up to focus on customer value much better than before.

Table Of Contents

Preparing the change: experiments, simulations, and co-evolution
Executing the change: learning to walk, then run, then fly
Will this ever end?