Agile transformations rarely fail by chance

‘Thank goodness. Our department is finally undergoing an agile transformation! It was sorely needed.’

Have you ever thought something like this? Probably not! Do you know anyone who has said this before? Probably not either! And that’s not particularly surprising, because transformations of teams, departments or entire companies – especially agile ones – rarely go smoothly.

Unfortunately, the success statistics for agile transformation paint a bleak picture, as many fail to achieve the actual project goal or fail completely. It is therefore not surprising that numerous employees have had repeated negative experiences with transformations.

So what can you do to make your agile transformation run more smoothly? You can actively address the perspectives of those involved.

WIIFM in an agile transformation

Are you familiar with the acronym WIIFM? WIIFM stands for What’s In It For Me.

Essentially, WIIFM describes a fundamental principle of perception, according to which people only pay attention to information if they understand why it is relevant to their own situation. So: What do I get out of a new product, what do I get out of a service, or what do I get out of an agile transformation?

Anyone involved in agile transformations and, consequently, the goals and benefits of such a project should consider WIIFM from different perspectives:

• From the perspective of the company,
• the managers, and
• the employees.

An agile transformation does not happen out of nowhere. It pursues a goal. And ideally also a plan. If the people behind the transformation are so convinced of its significance and objectives, why is this not communicated publicly? Why is communication on this subject only taking place within the company? One starting point for the company to take responsibility should be to communicate this externally. This would give future applicants the opportunity to see how the company is dealing with a comprehensive agile transformation.

The company also expects an agile transformation to improve a number of key performance indicators. These could include increased customer satisfaction, faster product development, error reduction or further optimisations. Will these indicators improve relatively quickly? The probability of this is not very high. After all, an agile transformation requires patience to take effect.

The management level also expects significant benefits from an agile transformation. However, not only for the company, but also for themselves. Those who successfully support and implement a transformation may also be recommended for even more complex tasks and the associated increase in status. This assumption certainly does not apply to all managers in a company. However, without the involvement and participation of managers, agile transformation is doomed to failure from the outset. Therefore, managers should be fully informed about all aspects, implementation and communication. Depending on the framework, the introduction of agile teams can mean one thing above all else for managers: a loss of power. This is because a Scrum team has different roles, but no hierarchy.

Employees may hope for aspects such as greater autonomy or improved cross-team collaboration. It can become unbearable if the agile transformation is only intended to conceal obvious management gaps. Simply introducing agile principles and frameworks does not solve resource bottlenecks, knowledge gaps or problem identification. However, it can increase the likelihood of making these visible. Subsequently, action can be taken (such as introducing agile retrospectives to continuously improve collaboration). Ultimately, it is the employee level that implements the agile transformation and utilises its effects in their daily work.

Successfully implementing an agile transformation

Agile transformations rarely succeed on the first attempt. Many organisations start enthusiastically, sticking up Post-it notes and introducing daily stand-ups, only to realise after a few months that the great revolution is more like a gentle evolution. An agile transformation is not a sprint, but a long-distance run without a fixed route: the goal shifts, the route changes, and sometimes you even have to run back a bit to move forward again.

The kick-off almost always follows a familiar ritual: a strategy workshop, a PowerPoint presentation entitled ‘We are going agile,’ and, of course, a roadmap – nicely visualised, with six phases, quick wins and a clearly defined end date. After all, you want to show that even the transformation to agility is well planned. Ironically, this is precisely the first contradiction: agility is introduced like a classic project with a target date, deliverables and status reports.

Successful implementation therefore does not begin with a master plan, but with a clear purpose: Why do we actually want to become more agile? Is it about faster products, more satisfied customers, more motivated employees, or simply about ‘not being left behind’?

Only when the “why” is answered honestly can the ‘how’ be meaningfully designed. After that, it takes patience and consistency – unpopular, but true. Transformations rarely fail due to a lack of (agile) frameworks, but rather due to premature impatience. Many organisations fall back into old patterns after the first few stumbling blocks. Failure is part of the process, and anyone who believes that agility can be introduced without friction should perhaps stick with the waterfall methodology in project management.

Support at all the levels mentioned is also crucial. It is not enough to train teams if management continues to think in terms of quarterly targets and measures success in terms of capacity utilisation. A transformation needs active sponsors who are involved. They must visibly live it, even if the first iteration goes wrong.

And, of course, communication. Every agile transformation is essentially a communication project. If you don’t explain why something is changing, you create uncertainty instead of change. Transparency, feedback and dealing honestly with resistance are not soft factors, but the decisive difference between ‘becoming agile’ and ‘acting agile’.

Last but not least, learning spaces are needed, i.e. places and times where teams are allowed to experiment without someone immediately asking how high the ROI of the transformation will be. Learning takes time, but not learning costs significantly more in the end.

If you like, the successful implementation of an agile transformation is not a project with milestones, but a permanent organisational learning process. A process in which the target vision is clear enough to provide orientation, but flexible enough to allow for new developments. Or, to put it ironically: an agile transformation is successfully implemented when no one talks about transformation anymore because it has long since become part of the corporate culture.

Figure: Five cornerstones of successful transformation

Conclusion

There are various challenges involved in an agile transformation. The architects of the transformation should communicate this in advance. Those who are prepared for this will ideally be better able to deal with it. Nevertheless, it is very likely that those involved will feel overwhelmed. It therefore makes sense to understand the perspectives of these interest groups – the company as such, the managers and the employees – from the outset. WIIFM – What’s In It For Me, i.e. what do I specifically gain from the transformation – should become the guiding principle of the project. And this guiding principle provides the framework for acceptance of the change, because without the acceptance of those involved, an agile transformation cannot succeed.

Notes:

Agile transformations are not a sure-fire success. Talk to Niklas Magerl about how you can take the different perspectives into account early on in your transformation – directly on LinkedIn.

Here you will find a series of articles on the challenges of agile transformations: Agility? We tried it! Does not work!

Would you like to discuss the success of agile transformations as a multiplier or opinion leader? Then share this article in your networks.

Niklas Magerl has published two more articles on the t2informatik Blog: