Agile transformation – how to do it right?

What exactly is agile transformation? What can you imagine under that? It’s starting to be one of the most inflected terms lately. Unfortunately, we hear rather scary stories about how it failed and what didn’t work out. When we ask for details, very similar patterns begin to appear in the answers. We encounter unpleasantly often very dysfunctional cases of attempts to adopt agile principles. It is not exclusively about corporations, but they are represented very often. It seems that running Scrum or some similarly agile approach is really difficult in such environment. And it is true. But why is that so? Do we need agile transformations at all? And what can be done about it? What is good to avoid?

In his book, Simon Sinek exhorts: Start with why! This also makes great sense for agile transformations, which is why we have already addressed this in this article. In short – times are changing, business and change are faster and only those who will be able to adapt fast enough will survive. In this direction, agile transformation is also usually focused – to shorten development cycles, to better respond to changes in the environment, to deliver better value to customers, etc.

What exactly is an agile organization? Where should agile transformation point?

To avoid misunderstandings, I do not see agile organizations solely as a cluster of pure scrum teams or anything like that. It is clear that different solutions with higher or lower rates of agile elements used will be suitable in different environments. Some organizations, even in their “agile form”, will continue to deal with some operations through simple processes (reception, cleaning, accounting …). Probably with a high degree of automation and UI (various chatbots already work today, the SW will generate a contract for you, etc.). Some changes will continue to be addressed in the form of “classically” conceived projects – wherever it makes sense (moving within a week, moving the production line, …). See my article on the CYNEFIN concept.

Attributes of an agile organization

On the other hand, it is necessary to mention that agile organizations in my point of view:

• is focused on the value delivered to customers,
• solves complex situations with adequate approaches (eg scrum combined with lean startup or design thinking, etc.),
• has the flatest possible organizational structure,
• has a suitably formulated and determined meaning of activity, an existence that gives people a sense of their action,
• it enables people to be motivated by giving them the possibility of autonomy, mastery and the above-mentioned meaning (see D. Pink and the book Drive),
• management creates an environment for the work of self-organized and self-managed teams and individuals rather than directly commanding,
• they have a high level of culture in which people trust each other, they are open and error is not perceived as a problem, but as an opportunity to learn.

Certainly there would be other characteristics, but honestly, even the above is quite ambitious, right?

Any organization can be agile

I definitely don’t write just about companies developing software. I have already had the opportunity to see first-hand agile teams in PR and marketing, HW development, laser machine development, etc. Usually it’s the development of something new, the development of existing services, product development, etc. Which is all right and it belongs to Cynefin complex domains. By the way, the SCRUM guide understands the “product” (around which the whole SCRUM revolves) as a product in the broadest sense, a service provided or even the management of the organization as such.

It is clear that the SCRUM team is primarily something like a production line that can produce high value very well under suitable conditions. At the same time, however, product development processes, product design, or other suitable process must also work in the organization, which will create good assignments for the given scrum teams. SCRUM alone does not address this issue.

So, for example, if you have a web content management system with 150 customers, you can understand that product as the content management system. And you can already manage to put together a SCRUM team. A stable development team that will be cross-functional and self-organized. Its Product Backlog will meet both the requirements for system development and the requirements of existing customers (and to organize this will be a task for the Product Owner). It probably makes more sense than solving 150 different orders or projects separately … and somehow even trying to develop the product further, but there will never be time for that ;).

An unsuccessful agile transformation

What did I mean by those scary stories in the beginning? First of all, that it doesn’t work well at first glance and everyone around them is upset about it. Management, internal customers and developers (and in the worst case, external customers). Agile is somehow being done, but somehow that’s not it. Typical problems are, for example, situations such as:

• Development is made in cycles – but only within a small part of the organization, which is still very much connected to the rest.
• There is a product backlog (a long list of items to solve), from which the team gradually removes. Requests from different parts of the corporation and for different products and projects or operational interventions often converge there. Which, among other things, means that even though teams are cross-functional, there are still a huge number of links to other teams.
• There are reviews that are more of a demo of the developed code than a demonstration of the value created for the customer.
• Developers have never actually seen a customer and do not even know the vision of the product – just a list of functionalities, which is more or less mysteriously prioritized in some way.
• The product owner is the person whose responsibility it is to take care of the product backlog. But she often does not own the budget and is not directly responsible for the business results of the product.
• And more – see also our previous article about Dark Scrum.

Do you recognize any of that? Is it familiar to you? Unfortunately, we see some (or all) of this often (eg from participants in our Agile and Scrum training, or at various conferences and other professional events).

Why can an agile transformation fail?

The causes of difficulties in performing agile transformation are probably not only in the insufficient training and knowledge of the actors. This is rather a manifestation, a consequence. The real reason of an agile transformation fail probably lies deeper. In principles, philosophy, culture. This is nicely addressed, for example, in this article about the trap in copying the Spotify “model” (note: This is not a model or a framework, just a description of the current state in one division of Spotify a few years ago). Among other things, it says that without Spotify culture (based on trust, innovation, autonomy, experimentation and the least possible bureaucracy), the attempt to deploy this “model” is doomed to fail. Another thing is that if one way of working works well for a certain company and its context at a certain moment, it does not mean that it is suitable for you at all. It’s okay to be inspired, but to copy them in this case is more of a road to hell.

Corporation’s immune system

In his book “Exponential organizations“, Salim Ismail calls it a reaction of the immune system of a traditionally conceived corporation. Such a corporation is, in essence, primarily focused on maintaining the status quo, minimizing change and preventing risks. And it stifles all attempts to change something.

Typically, all steps in such a corporation are considered and approved at many levels, and what has already gone through this machinery is very difficult to change in any way (of course, this leads to the situation that before the information reaches the appropriate level of approval, the situation is on the spot already different and therefore deciding on something that is no longer current… etc.). In today’s fast-paced world, it’s a pretty deadly cocktail – as people from Nokia, Kodak, Blockbuster, Thomas Cook and many other corporations already know.

In any case, these approaches and values ​​are very deeply inscribed in the “DNA” of the organization. It is about the efficiency and productivity of inappropriately set processes (set for success in the 20th century … not in the 21st century). The management system is based on carrot and stick, a relatively strict hierarchy and the career advancement of many levels of this hierarchy. In more extreme cases, it is possible to speak of a certain culture of hypocrisy and “knives in the back” in the interest of career growth (the system behaves as measured). Attention is focused on internal politics and career ladder also because the customer is something very distant and imaginary.

And now agile …

And now add the ever-changing agile… (essentially a permanent change). Which is not about productivity, but about the value delivered to the customer. Which needs the flattest organizational structure and the most frequent and closest contact with the customer for a good function. Trust within the team and the entire organization and mutual respect. So something completely different. It just can’t work well together and it won’t. It usually ends with a game of scrum rituals, without affecting the behavior and attitudes of the actors (more in our earlier article on Dark Scrum).

Consequence?

It’s a bit like Hong Kong – the bubble of democracy in a totalitarian regime. It also doesn’t work well. Like an agile in a corporation that is strongly hierarchical, procedural, and controlled by the carrot and stick method.

The intended change should therefore be systemic, complex, considering the whole context (which is definitely in the complex Cynefin domain). Changing the way one department works can be a good start, an experiment, but it won’t work without further follow-up with an impact on the entire organization. That is, if you want to be (more) agile… Agile in a corporation cannot work in the style of “just one or more small parts.” At least one large or sufficiently separable part must be changed in its entirety.

So how to do an agile transformation?

There are two basic approaches, evolutionary and revolutionary. Or something like “spin-off”. Today, it is probably too early to judge which one is better. It can also be different in different contexts. In all cases, however, there must be a good and strong reason for such a massive change. One that retains energy for change long enough. One that you are able to communicate effectively across the organization and gain allies. One that is understood and accepted by management and everyone else. Otherwise, you will end up somewhere halfway in the states described above.

The reasons can be different for different organizations – faster “time to market”, better satisfaction in the team, higher product value, etc. The link between the lines will then usually be the desire to survive and develop further. Because if a company is thriving and growing, no one will feel that change is needed. It’s definitely not a good reason that others are trying, so let’s try it too … such a reason doesn’t have enough energy.

It is important to capture the right moment in this context – we are still well, but we can already see that it is going down … at that moment it is appropriate to start an agile transformation (of course only if it is the change that can help in the given situation: )).

Evolution

The first way to transform agile is to work on your change. That is, gradually, but across the board, you are changing the culture. Gradually, you supplement the missing competencies, change attitudes, the level of trust, etc. Thus, you prepare people for a new concept of work, which you gradually move on and in a controlled way, iterates to it in small steps.

It is, of course, a slower path, but also with less immediate risks. Gradually, you show people new and new possibilities and spaces, and it’s not such a big culture shock. Of course, only if you have a functional vision, which direction and why you want to go. And also a very good reason to do it and also time to do it (see above).

And as Lao-C´ has already said, the journey of a thousand miles begins with one step.

On the other hand, there is a risk of underestimating the immune response of a traditional corporation, which will quickly tick off the hippie experiment.

Revolution

The second path is much more radical. You just make a big bang and rearrange the organizational structure for an agile concept of work. And you rely on that it will sit down and people will learn to walk in it. And with retrospectives, you get it in a reasonable state. Of course with the support of agile coaches and the whole team that takes care of the change (without it, it is pure suicide).

This approach is based on the principle that the system and its processes largely create and “cause” a culture. Which can be agreed with (although the not very good examples are more visible).

And it also somewhat evokes the problem of hen and egg … does the organizational structure produce culture? Or does culture produce an organizational structure?

Of course, the risk of an immune reaction is lower here – you don’t give it time. On the other hand, there is a clearly higher risk of overall system failure…

Of course, it is necessary to change the whole organization or its significant, de facto separate part (for example, IT in the bank).

Sometimes, when using this strategy, agile transformations of companies commit a certain touch, in which they set a target state, which they then introduce through a waterfall and feel that it will be met. But that doesn’t work. In fact, an agile company is constantly changing itself in the form of retrospectives … so there is nothing like a target state. Agile cannot be a target state. It’s a way, a way of working that should help you achieve real goals!

Spin-off

The last option is to build a de facto new company on a green field. Such a new company (startup) can either target new markets or even try to “disrupt” the business of its founder. Dozens of startups are trying to do it anyway, so it’s better if yours does it than a stranger. And you are taking this path when you recognize an existing corporation as incapable of change, let alone such a fundamental one.

The key to this procedure is real separation from the mother. Otherwise it doesn’t work. E.g. In 2007, Yahoo Corporation created its Brickhouse internal incubator. One of the best development teams of that time was assembled in it. But… Yahoo wanted this team to create internal solutions, instead of connecting directly to customers or new opportunities and markets.

Yahoo’s immune system reacted naturally to this foreign object. Very soon all traces of autonomy were erased and, on the contrary, jealousy and resistance across corporations rose. “Why should they have the best employees?”, “Don’t they happen to endanger MY product / project / anything?”.

In 2008, Brickhouse’s experiment was terminated. Yahoo’s immune system won the battle but lost the war. Yahoo no longer exists today… which brings us back to the reason why higher rates of agile in the corporation should be considered.

What to take from it all?

An agile transformation should be dealt with wisely, comprehensively and for good reason. Which will probably be found sooner or later (perhaps not too late).

Not everything has to be solved immediately by Scrum and it itself does not solve everything either. There will still be some work in simple processes. It will make sense to still deal with some changes in a rather predictive way (albeit with a high use of agile elements, team autonomy, etc.).

Managers as such may need a little less, but still someone will have to manage, develop and define the system as such, the rules of the game and the pitch on which the self-organized and self-managed teams will play. Just like a gardener, he determines the basic layout of the garden, which he then maintains (he fertilizes here, spits something out here) … without which a jungle would form in a while;).