Much has been written about the agile transformation of organisations, its importance in the context of digital transformations, but also about processes, methods, roadmaps and best practices.
However, many Agile coaches and authors like to give one topic a wide berth, even though this very question causes many organisations a real headache in practice. One reason for this may be that this question only arises in practice, because in theory, everything always looks quite simple and plausible.
The question is how teams are actually transformed, i.e. how do I make an agile team out of a grown team that has been working together for many years and has also been quite successful, at least in its self-perception.
In my observation, it doesn’t matter so much whether the team comes from a classical method or already thinks it is already agile because it already works according to Scrum. I have to explain the latter briefly.
Many teams have already tried to implement an agile method – mostly Scrum, sometimes Kanban, occasionally even Scrumfall (not Skyfall) – were not very successful and are supposed to learn the agile tools again properly. Many organisations and even more agile coaches know the problem.
How do you teach such teams an agile mindset?
This is exactly what this article will be about, i.e. I will try to summarise my approx. 15 years of experience with this topic here and make a proposal for discussion.
Agile transformations – the difference to classic methods
Agile transformations always feel a bit like therapy, at least that’s how they are often organised by agile coaches, and the patient doesn’t always feel better after the therapy.
Some patients have unfortunately also died during such therapies, projects have failed, organisations have pulled emergency brakes, and occasionally they have switched back to the classical methodology.
What makes agile transformations so difficult, or why do agile coaches often make it so difficult? First of all, I will try to give a short answer.
Classical methods focus primarily on roles, processes, architectures and artefacts. Requirements specifications, specifications, estimates, reporting, supply chains, organisational charts, responsibilities, control, project controlling, quality gates, etc., everything is well organised until the monument is unveiled.
The starting point of agile projects is often the absence of such structures, artefacts and processes and the realisation that both the time will not be sufficient to create them (time-to-market) and the complexity of the subject matter makes such a planning and organisation process almost impossible.
What then remains are the actors on whom one must now rely. Agile methodology therefore focuses much more on people, trying to enable the actors to do what is necessary now. Changing people is far more complex than changing processes.
The right approach for the agile transformation of teams
In addition, agile coaches unfortunately often take this context too literally and thus open up a game that they cannot actually win.
Agile coaches follow what I would call a psychoanalytical approach, focusing on the intrinsic motivation of teams and their ability to organise themselves. Motivation and self-organisation are undoubtedly very high values and desirable goods in the agile methodology.
However, it is often overlooked that both have to be learned and can be learned, but cannot be assumed and perhaps do not have to be assumed at all. The latter is crucial for my approach.
In concrete terms: How do I turn a team into a well-functioning team that feels no motivation to change fundamentally at the beginning?
To achieve this, I use a different approach, a more behavioural approach. Even though both terms come from psychology, they are of course only used here as a metaphor to better distinguish between two transformation strategies.
Therefore, in the following I will call the psychoanalytic approach the P-approach, while I call the behavioural therapy approach the V-approach. But allow me at this point to add a short sentence for each of the two approaches for better orientation.
Psychoanalysis is supposed to bring conflicts to light through conversations and free association. The person should therefore recognise for himself what is going wrong and develop a new or adapted strategy for action from this.
In the most positive sense, this comes very close to the coaching idea and is therefore also preferred by agile coaches. Two points are often underestimated.
Firstly, this often takes a lot of time and secondly, it requires an intrinsic motivation on the part of the teams to get involved in this game. Organisations often have this motivation, but teams often do not. So what often works quite well at the organisational level often fails at the team level.
Prepare Agile Teams
At the team level, we therefore need a different approach in such situations, a more behavioural therapy approach. The core idea of behavioural therapy is that (problematic) behaviour has been learned and can also be “unlearned” again, or new, more appropriate behaviour patterns can be learned.
In somewhat simplified terms, it is sufficient for the Agile Coach as a prerequisite here that the team members voluntarily show up for work in the morning and take instructions from authorities assigned to them.
High motivations, curiosity, creativity, willingness to learn, critical faculties, etc. are all of great advantage and very helpful, but are not necessarily assumed, in other words, we also have to cope if these qualities are not as pronounced as we would wish.
In practice, this means that the methodology is more or less prescribed in the form of instructions and not developed with the teams as in the P-approach. Of course, this sounds harsh at first and also contradicts the agile ideals. And to some extent it probably is.
But it can also be seen as a shortcut that is no less sustainable in the end than the P approach.
In short, in the V approach, we assume that once the behaviour is learned and successes are recorded, insight and motivation will already occur.
Teams should learn quite quickly that the agile method helps them to manage their tasks, instead of feeling that they have to invest a lot to make the method work. The prerequisite for this is not the insight that this is the case, but merely a certain degree of willingness to follow it.
Develop an agile mindset
Of course, agile culture and agile mindset cannot be prescribed, as the critics would now easily interject.
That is not the V approach either. The latter says it can be learned. In practice, this means that – let’s call him “Chief Scrum Master” or, as SAFe would say, Solution or Release Train Engineer – specifies the methodological artefacts, team setup, sprint length, definition of ready, definition of done, meetings and their frequency, templates for stories and epics, the estimation procedures and the handling of story points, use of tools, all the things that are the responsibility of the teams in the P approach are specified in the V approach.
In positive terms, this gives the teams a lot of orientation. After all, in the background there is still a content-related task for the teams, namely to develop a product.
The mandate is not actually to come up with a method. Nor should the traditional agile call for teams to self-organise – and I think this is a misunderstanding that many agile coaches succumb to – be understood as the call to
Choose your own method, or customise it until you like it”, but rather means “use the method in such a way that you can solve your own problems in product development as far as possible.
Agile methods are always erroneously described as very flexible, but this is also due to a linguistic misunderstanding. The method itself is by no means very flexible, on the contrary, it is very stringent and requires a maximum of discipline. However, when applied correctly, it allows an organisation a very high degree of flexibility.
In the V approach, we indeed do not have to take into account the sensitivities of each individual. But it does not mean that the sensitivities of each individual are not taken into account.
Anyone who has ever worked in a school or hospital knows immediately what is meant here.
It is not a relegation of the individual, but we simply know that teams faced with such a challenge of using a new method and at the same time developing mind-bogglingly complex products need guidance and a clear mandate the most.
The method, helps you to focus, prioritise, develop. Recognising this is a learning process. The quickest way to learn is by doing, not by reflecting.
Addressing challenges for agile transformations in the right way
In my practice, I have often observed that Agile transformations tend to fail because teams lack this clear orientation: best practices that give them guidance on how to behave in difficult situations.
What to do if we have too many scope changes, if we never achieve what we set out to do, if we see too many dependencies on our task, if the meetings keep increasing and taking too long and we have no time to work, if we lack contacts, if our hints from retros are overheard, if the tools are not the way we wanted to use them, if we have constant conflicts with individual team members, etc.?
Only when all these questions have been answered in a reasonably satisfactory way can a culture with a corresponding mindset develop. This is only possible in this order, not vice versa.
However, we must not hide the fact that the V approach also has to contend with some challenges. If the agile method is given and established, i.e. it works, then a certain comfortable satisfaction quickly sets in for many actors.
As I said, the functioning of the teams in the method is important and fine, but the second step still has to take place. The second step is for the actors in the teams to change from “active” to “proactive”. The method does not go that far.
And the V approach does not necessarily have this reach either. So some work remains, but this work is easier on the basis of a well-functioning method than on no basis.
Motivation and proactive, as pillars of an agile culture, can in principle also be learned, even the joy of something can be learned.
Even if these thoughts are not particularly popular in society today, because they cast a shadow over us and our highly individual emotions of a certain heteronomy and manipulability. But that is taking things much too far.
We see that P-approaches and V-approaches can play important roles in an agile transformation. On the management and organisational level, we rather need P-approaches so that – and this is e.g. a central demand of SAFe – the management itself helps to initiate the transformation.
Here we usually have only a few actors, but with a high level of responsibility for the transformation process. In the teams, the situation is quite different. The teams are the core of the value creation and thus bear enormous responsibility for it.
But their responsibility in the transformation process is less great – when broken down to the individual. In order not to jeopardise the value creation process and to get agile methods up and running quickly, the V approach is more promising at the team level.
