Agile Myths: Agility equals Scrum?!?

As is commonly known, there are many myths surrounding the definition of agility. Today: Agile equals Scrum.

Agility equals Scrum !?!

After Scrum has become more and more firmly established in software development over the past 20 years, many people see it as the stereotype for agile working. But is that all? Is there something else behind the buzzword “agile”? Yes, there is, because Scrum is meant for product development, and not all work is product development.

The Agile Universe Consists of More

If we look at the agile universe, we can discover a stable core around which everything revolves: agile values and principles. They are stable over the long term and subject to little change.

Agile Universe

Agile frameworks are built on these values and principles. In addition to Scrum, many other agile ways of working, such as Scrum, Design Thinking or Kanban, also lie in this sphere. Agile frameworks provide – as the name suggests – a framework with which agile work can be done. These frameworks are quite stable, but changes occur here as well. An example of this is the product backlog refinement. This was not envisaged in the “original Scrum”. However, it has proven itself in practice, and so it was included in the Scrum Guide.

Around the agile frameworks there is a – very broad – set of (agile) working techniques. Techniques can be used, exchanged or adapted more or less arbitrarily within agile frameworks. Techniques are not assigned to any specific framework: for example, the Kanban board can also be found in the application of Scrum under the name Task Board.

This addition of techniques to the agile frameworks is also the reason why one speaks of “frameworks”: they provide a framework that only becomes operational through the addition of agile techniques.

Conversely, teams don’t have to use all agile techniques to be agile – think here, for example, of the broad set of prioritization techniques: Magic Prioritization, WSJF, and Kano, for example, have proven effective in dealing with agile teams. The key here is to pick and choose.

By the way, many of the agile techniques are not inventions of the agilists – code reviews, for example, is nothing more than the four-eyes principle that we encounter far away from product development in areas like due diligence.

So Agile Frameworks are Agile!

Does this mean, in reverse, that agile is the one who uses agile frameworks? – Not quite; let’s take the already mentioned example of Kanban: Kanban is derived from Lean Management, which was developed in the 1970s by Toyota, so far before the “inventors” of agile have dealt with what constitutes agile; indeed, they build on the knowledge that has been gained through the application of Lean Management, but you can implement classic Kanban without being oriented to agile values and principles. For Lean Management, only the Lean principles apply in the first place. The practice shows us however that Kanban can be compatible very well with “Agilität”, teams, which orient themselves at agilen values and principles, thus more productively become.

The matter becomes more difficult with Scrum: Scrum is by definition an agile framework, which means that whoever uses Scrum must be agile by definition. – In theory, this is correct as far as it goes. In practice, however, it becomes apparent that Scrum is often implemented under circumstances that impair or hinder true agility: If Scrum is seen as a fashionable or hip means to make teams more productive, this corresponds to a short- to medium-term view. However, it is often neglected that agile also requires a change in the individual value system or in the value system of organizations. As already mentioned, these are long-term change processes that cannot take place overnight. Agile approaches, frameworks and techniques are therefore applied to an organization that has not internalized the underlying values for itself. We more or less affectionately call this “Scrum theater”: A play is being performed on the public stage, but what happens backstage remains hidden from the viewer. – Perfect conditions to let an agile transformation fail and the buzzword “Scrum” burn.

So Work on the Values for a Few Years First?

Transforming Principles and Values

Of course, a healthy change process goes hand in hand in all areas – following the principles incrementally. It must be said at this point that the world is not black and white; techniques such as “delegation poker” show very nicely, using the example of “self-organization and empowerment”, that there can also be gradations in the question of how principles can be lived. However, it is crucial that anyone who wants to be #echtagil must develop their framework as well as their values in equal measure.

Leave a Reply

Your email address will not be published. Required fields are marked *

Your email address will not be published, nor given to third parties or used otherwise.