Agile Myths: Agility equals Scrum?!?

Now that Scrum has become increasingly established in software development over the past 20 years, many people see it as the stereotype for agile working. But is that it? Is there something else behind the magic word "agile"? Yes, there should be, because Scrum is intended 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 in the long term and are only subject to minor changes.

Agile frameworks are based on these values and principles. In addition to Scrum, this sphere also includes many other agile working methods such as Scrum, Design Thinking or Kanban. As the name suggests, agile frameworks provide a framework for agile working. These frameworks are fairly stable, but changes do occur here too. One example of this is the product backlog refinement. This was not provided for in the "original Scrum". However, it has proven itself in practice and has therefore been incorporated into the Scrum Guide recorded.

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

This addition of techniques to the agile frameworks is also the reason why they are referred to as "frameworks": they provide a framework that only becomes operational through the addition of agile techniques.

Conversely, teams do not have to use all agile techniques in order to work agilely - think of the broad set of prioritization techniques, for example: Magic Prioritization, WSJF and Kano, for example, have proven their worth when dealing with agile teams. The key here is to choose.

Incidentally, many of the agile techniques were not invented by agilists - code reviews, for example, are nothing other than the four-eyes principle that we encounter far from product development in areas such as due diligence.

So agile frameworks are agile !

Conversely, does this mean that anyone who uses agile frameworks is agile? - Not quite; let's take the example of Kanban mentioned earlier: Kanban is derived from lean management, which was developed by Toyota in the 1970s, i.e. long before the "inventors" of agile were concerned with what constitutes agile; although they build on the knowledge gained through the application of lean management, it is possible to implement classic Kanban without being guided by agile values and principles. First and foremost, only the lean principles apply to lean management. However, practice shows us that Kanban is very compatible with "agility", i.e. teams that are oriented towards agile values and principles become more productive.

Things get more difficult with Scrum: Scrum is by definition an agile framework, which means that anyone who uses Scrum must be agile by definition. - In theory, this is correct. In practice, however, it turns out that Scrum is often implemented under circumstances that impair or hinder true agility: if Scrum is seen as a fashionable or hip means of making teams more productive, this corresponds to a short to medium-term view. However, it is all too easy to neglect the fact that agile also requires a change in individual values or in the values of organizations. As already mentioned, these are long-term change processes that cannot take place overnight. Agile procedures, 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 performed on the public stage, but what happens backstage remains hidden from the audience. - Perfect conditions for an agile transformation to fail and for the buzzword "Scrum" to burn.

So work on the values for a few years first?

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" use the example of "self-organization and empowerment" to show very nicely that there can also be gradations in the question of how principles can be lived. The decisive factor, however, is that if you want to be #echtagil, you need to develop both your framework and your values.