5th of May '20
There are several reasons why you should and want to use agile frameworks. Depending on whether the decision is top-down (from management downwards) or bottom-up (from the ranks of the employees), the motivations are different. Employees often expect better quality, more focused work and better teamwork from agile approaches.
From a management perspective, the focus is often on accelerating processes, improving quality and, above all, increasing agility, which should enable companies to react quickly and easily to changes. Increasing employee satisfaction can also play a role here.
But before we talk about the different agile frameworks, I would like to point out one central thing that I have seen in many agile projects.
Much more important than choosing the right framework is a complete understanding of agility. If you want to scale something, you need to make sure it works on a small scale before you scale it - otherwise you make big problems out of small problems.
So let's return briefly to the expectations placed on agility (often synonymous with "SCRUM"):
As already described above, there are often different expectations of agility. On the one hand, managers often expect increased quality, a faster release time from the decision to the product (time to market), increased efficiency and ideally also more satisfied employees.
On the other hand, employees often expect to be able to work more freely, to focus better on their work (instead of having to deal with politics and processes), as well as more pleasant teamwork.
There are two essential insights that I have made in projects:
Agility/Scrum often becomes the projection surface of our wishes. This means that, as described above, the project participants often expect different things from agility. This does not necessarily have to be bad - but it is essential to bring the other understanding closer to both groups, so that ideally both circles overlap. If this is not the case, the participants pursue different wishes and goals, which can lead to strong conflicts. The other’s point of view is often the blind spot for the participants, which has to be reduced.
In the middle of both circles there is something that may be unknown to both sides. One of the secrets of the success of agile frameworks is that they replace typical slow structures with efficient processes and roles to quickly reveal problems. However, this change does not always have to be desired. As you can see, the key points in the middle have negative connotations. This should underline that these things can often be perceived negatively. One of Scrum's top credos is the creation of transparency. Transparency is necessary to draw attention to problems and to eliminate them (Thus making the team more efficient). However, openly addressing problems can quickly be uncomfortable. Here one must strongly moderate the expectations in advance. The same applies to clear responsibilities. Scrum clearly regulates the role of Product Owner, Scrum Master, the team and the stakeholders. In between there is no "maybe this is not my responsibility". But this also means that people have to accept responsibility. For some this may be liberating, for others it is rather frightening. Trust" is also central to frameworks like Scrum or scaled frameworks like SAFe or Nexus: Leaders are expected to trust their teams and not "interfere" with them. In bold terms: self-organizing teams instead of command-and-control structures. It is easy to see that these changes are not just catchphrases, but values people have to live as a culture. Those values and attitudes are something that we humans often ascribe as unchangeable in a person, such as behavioral patterns or core values. Some people can accept such changes, some simply cannot.
Before we take the next step towards scaled agile frameworks, my call is therefore: Ask yourselves: Do we really live agility and do we stand by the values of Agile/Scrum?
If you're not sure, I suggest you do an agile assessment. Either only for yourself, or even better: with your Scrum Master/Teams together. There are many approaches that can be found via Google under the keyword "Agile-Assessment".
If you can answer "Yes" to all points in your teams, you have created a solid basis to be able to turn to the next step of the journey: Choosing the right framework for agile scaling.
Originally the first article in this blog was supposed to deal with the selection of the different scaled agile frameworks. However, since creating the right prerequisites is at least as important as choosing the right framework, this two-part article series was created.