The main thing people get wrong about transformations is that they try to make them too big, too ambitious, and too long. The most interesting transformation I worked on involved, or intended to involve:

Transforming the mindsets of 2000 people divided into 20 tribes

100 coaches of about 4 different types

A 3 year time plan

A new delivery model based on SAFe

Lean continuous improvement

A new organizational structure based on the Spotify Model

Objectives including increasing profitability, increased Net Promoter Score and automation and reducing dependence on the external workforce

A complete migration from a mainframe based architecture towards containerized micro-services in the cloud

A business transformation involving switching the company from a consumer facing brand to a supplier of B2B banking services to consumer facing startup brands

For a coach it was a lot of fun. It doesn’t make sense to talk about success or failure of transformations. Any transformation is likely to make some kind of positive impact, but might not achieve the expected RoI, and probably won’t reach all goals in the expected time span. It might even endanger the company if it is too ambitious. The company could get to the bottom of a J-curve it might never be able to climb out of.

You should probably only ever need 1 transformation

I am always bemused by companies that jumped on the Scrum bandwagon back in the good old days around 2008-2012. With a transformation of course. That should have been it. If every team had a Scrum Master providing services to the organization, and regular retrospectives, there should never be any need for any other transformation. That mechanism should have been enough to evolve whatever else might be needed over the next decades. If you needed e.g. Scaling, then the Scrum Masters would have organized themselves into Scrums of Scrums within the department, and identified representatives to coordinate with each other across departments all the way up to the board level. Whatever else is needed would be discussed and implemented as teams, and departments identified impediments, or experiments to improve the system, documented and shared them, and implemented them across the organization. It didn’t turn out that way because Scrum Masters (typically with a software developer background) shied away from providing such services to the organization, shied away from anything financial or involving talking or working with senior management, especially outside the programming or IT departments. They tended to retreat into their comfort zone of being a kind of junior team assistant, planning and moderating the Scrum events. It wasn’t always their fault. Many of them never saw a chance against the alpha personalities of the PMs-turned-POs and other tough-nosed management types in the organization who were happy to keep the SMs in their team-level boxes.

Keep it simple stupid

You should probably just pick one organizational level, one objective, and a relatively short time-box, say 3 to 6 months. Just like anything in agile or lean, we want to keep our batch sizes small, and our timeboxes short so things don’t get out of hand and any potential waste is limited. In order to prevent the need for any other potentially disruptive transformations you should focus on something that includes some kind of continuous improvement mechanism. The purest form would probably be some kind of “lean continuous improvement” transformation, avoiding introducing any new organizational structures, delivery models, or radical new mindsets. However some approaches such as introducing Scrum in the product development teams, or Kanban at the departmental level can help you kill two birds with one stone by improving delivery and introducing continuous improvement at the same time. Another nice approach is establishing departmental leadership teams that focus on improving the system at a strategic level (i.e. letting the teams deal with the small day-to-day operational issues) by conducting experiments or resolving departmental level impediments with something like A3 problem solving workshops or PopcornFlow.

Once you have introduced a continuous improvement mechanism (I use the word mechanism on purpose. Culture comes later), that mechanism should take care of anything else a transformation might be used for, whether it be to modify the organizational design, introduce a new delivery model, migrate to a new architecture, improve specific KPIs or evolve a new business focus.

Use the pull principle

To get the best bang for the buck, and find the best alignment of organizational objectives, employee needs, and overall approach it might be best not to be too pushy and decide up front what everyone needs. Set up a Lean Agile Competence Center of experienced managers and coaches, let them unpack their toolboxes in front of the organization and see who bites. There are bound to be departments who already have pressing needs and are hungry for assistance. This way you can keep a very tight alignment between what is actually being delivered and what is needed.

Don’t start by shoving some new, abstract culture down people’s throats

One common phrase I have come to despise is “it is not enough to do agile, you have to be agile”. Nonsense. What right do any of us have to decide who other people should be? Most people don’t give 2 shits about agile. Why should it become an important part of who they are? It should be perfectly sufficient for most people to merely operate the system as designed, to fulfill their role as described. Sure, managers like scrum masters or agile delivery managers should “become agile” to some degree, but most people should be able to work happily with the support of “agile” in the background and rather focus on “being” better technicians, bankers, product specialists, business analysts or even fathers, mothers, musicians, swimmers, or poets than orienting their lives around a 20 year old manifesto related to how software development teams should structure their work.

I am not saying we should pretend that culture & mindset is not part of the new agile organization, but we should not start there. The new culture and mindset can only emerge once people have a new system to operate. If this system is not in place, pointing the finger and demanding things like self-organization or servant leadership will only lead to frustration.

4 Stages of a transformation

Pre-Transformation

As hinted at above, before any kind of transformation you have to have the support you need. Experienced coaches and managers bringing their tools with.

The minimal transformation

The transformation itself should be limited to 3 to 6 months, and should focus on continuous improvement. This is not the time to introduce a whole new organizational design or enterprise level delivery model like SAFe. Start small. Introducing Kanban or PopcornFlow is a good choice here. Or regular Problem Solving Workshops using lean techniques like A3. Scrum is fine too provided the Scrum Masters are more senior than junior and don’t hide away in the teams and the pages of the Scrum Guide, and embrace their role of providing services to the organization, and connecting together to take over the operational and organizational needs of the enterprise.

After the transformation part 1 – improving the system

Once we have introduced the mechanism of continuous improvement, even if it is mostly just in the hands of the Scrum Masters or external experienced agile managers or coaches, we should stop talking about the transformation. From here we can rely on these mechanisms to give us whatever else we need. Whether it be new organizational structures, or other systemic improvements to increase alignment of delivery across multiple teams or departments. This should be seen as a normal, day-to-day part of life in the organization rather than an exceptional, disruptive aberration from the normal delivery of products and services. This is where we would see things like SAFe or the so-called spotify model appear.

After the transformation part 2 – the emergence of a new culture

If people are focused on learning a new continuous improvement mechanism, or using that mechanism to improve the way they do their work then that is quite enough. Eventually, as they get experience with operating this new system that they have helped developed they will realize that there are new ways to think about the culture of the organization, the new role of management, the new power they have has workers and increased effectiveness of shortening the distance to the customer and allowing a radical new mindset to develop. This can only happen as fast as, and follows, the introduction of the more mechanical systems first. It probably will only happen once the focus on improving the system slows down and people can allocate some mental capacity to thinking about things like culture and mindset.

This would also apply to a more typical overly-ambitious big-bang (or even Kotter) style transformation. In fact I would say the new culture & mindset can only begin to emerge once the transformation is over.

Miscellaneous tips

Whatever style of transformation you choose (big and ambitious or small and focused on continuous improvement mechanisms) make sure someone at the board of directors (or at least the main leader at whatever organizational entity is transforming) sees it as his pet project.

Train people in bulk. Use training as a chance for people across the organization to meet each other and share experience and thoughts. Let experienced coaches focus on coaching Scrum Masters and other managers and allow those managers to coach and train the teams. It is also quicker and cheaper this way.

Communicate everything transparently and continuously, inviting feedback every step of the way. Remember we aren’t transforming people here, we are allowing people to transform their system.

Make sure any introduced models are fit for purpose. SAFe has a purpose (increasing alignment between teams in departments developing products together) but it is not an organizational design framework nor is it suitable for service delivery and it is not that strong in continuous improvement either. Make sure you understand what you want to achieve and pick the right thing for the job.

Don’t pick a cool department and focus on transforming it as a kind of pilot project. That send the message that everyone else is unimportant. Instead set up a pool of coaches and agile managers and allow those to pull from it who have the most need.