Agile Transformation: Why adopting comprehensive agile models will not solve the problem

When you look at agile models, you quickly get the impression that they come along as prefab sets. Depending on what you want, you get a different set recommended. If you want to transform the entire organization, there is SAFe, NEXUS, the Spotify model or holacratic circle structures. For a focus on innovation, models like design thinking, business model navigator and co-creation will serve you. And agile project management can be done with SCRUM or XP.

These methods and models are attractive because they offer guidance and accompaniment from the first step to the last. However, as ready-made kits for organizations, they function according to the "all or nothing" principle (think of "ScrumButs"). This has the disadvantage that the solutions they offer do not fit every organizational problem. Existing structures are disregarded, which can have undesirable effects, or worse, none at all: being agile is declared, but no one bothers.

We have a suggestion how to avoid this scenario: Don't take a prefabricated agile kit as a whole, but disassemble it into its individual parts. With a sober view, e.g. freed from the exaggeration of the discourse, one can pick only the agile design elements that are useful for the organization. This can be proceeded as follows:

First step: understanding one's own organization

Before getting into all those promises of salvation agile models have to offer, you need to look at your own organization. Taking a sober look at agile models also means facing a truth: Agile models do not serve as an end in themselves and they won’t improve the situation of the organization just by proclaiming them. One must be aware what exactly should change, or in other words: if agile methods are the solution - what exactly is the problem?

Why being uncreative can be a solution

Let's say you're flirting with agile innovation models because you want your employees to stop approaching problems in the same patterned way. You want them to become more creative. Then it is worthwhile to investigate a few questions: How is creativity actually handled in the organization? What mechanisms does the organization use to deal with ideas which are out of the box? What happens when a process cannot be mapped on the pattern which are typical for the organization? Are there social sanctions from within the college for deviations, and if so, what might be the background?

Sometimes the cause of apparent lack of ideas is a tight set of rules that demands explaining every single move if one leaves the usual paths. Then it is easier not to leave the pathes at all. A different reason could lie in the organizations’ informality. If the employees made the experience, that new ideas just mean: more work on top, they defend their amount of workload by being uncreative.

These are two different problems whose solution looks like a new problem: Uncreativity. But if you introduce an agile model that is supposed to support creative thinking, in these circumstances, you can consider yourself lucky if simply nothing happens, and the employees simply ignore the input.

Which design principle do I need for the problem?

Only after understanding the reference problem the organization faces, you can turn to the solutions agile models have to offer. Given that it is now the search for a specific solution, the question now is no longer, "Which agile model do I need?" But rather, "Which design principle of agile methods do I need to solve this specific problem?"

For the example described, they are two solutions at hand, depending on what the reference problem is. To deal with too strict formality, one could start a trial with self-organized teams that do not work process-oriented but result-oriented. Too high workload can be addressed with sprints or time boxing to eventually create gaps in tight schedules. Which design principle contributes to the solution will then become apparent in practice.

Roll out agile transformation: Step by step, open for change

A transformation process can generate new problems for the employees. Reasons can be for example the lack of routine, which produces insecurity. The transformation can mean a loss of power for some members, or it creates problems in places that previously had none. Experience has shown that members will not quietly accept this but question if the process is worth the effort.

If you talk about mindset, you lose

Criticism and resistance to transformation is often wrongly attributed to a fear of change within the employees. It is presumptuous towards the employees to consider them as too small-minded to recognize their own happiness and that you only need to find the right words to convince them. Mindset appeals are the sure way to make a transformation fail because you show that you don't take your employees seriously.

Much higher chances of success come from looking for the rationales in the resistance. There could be a chance to include the criticism into the ongoing transformation process. Therefore, it is important to flag the transformation as contingent: The outcome is not yet fixed and changes are possible.

Draw learning loops, incorporate experiences into the process

It should be self-explaining, but the implementation of an agile design principle should be approached iteratively. For example, you can roll out a transformation for a part of the organization and try it out on a small scale. By consciously deciding on a design principle beforehand, it is easier to formulate expectations about what one hopes to achieve by introducing the method. This hope can now be compared step by step with reality. And if the changes fail to materialize, the next question is also clear: What do we need to adapt?

Agile transformation turns from a matter of faith into your specific tool set

?It is therefore worthwhile to reduce agile models to their basic mechanisms. If you free them from their claims to be a universal solution and - just as importantly - their charge to be a matter of faith, it becomes possible to use them to constructively shape the organization. Their design principles can now be used in the same way as the contents of a toolbox are used: Sober, factual and effect-oriented.