The Agile Manifesto describes what is important in agility. Individuals and interactions are more important than processes and tools. Working with the customer is more important than negotiating contracts. Agility is therefore a model based on trust, and collaboration.
Agile software development today mostly means Scrum. The term “Scrum” comes from rugby sports. The term refers to a process in which the teams fight for the ball after a minor rule violation. Rugby has a high risk of injury. Anyone who has ever seen a picture of a Scrum in a rugby match will certainly not think of trust, or collaboration as the first associations. After all, it’s a fight for the ball.
But “Scrum” is not the only problematic term. A Scrum team works in “sprints”. Also the term “sprint” is a term from a sporting competition and hardly stands for collaboration. A collaborative sprint race would be rather absurd. For example, there is the three-egged race.
In addition, “sprint” stands for a short effort. This is actually weird: product development consists of a large number of sprints. It is much more important to be successful in the long run - and that is not what is important for a sprint in sport.
Velocity defines what a Scrum team can achieve in a sprint. In a competition, the higher velocity wins. This is not the case with Scrum. The velocity is used to estimate what can be delivered in a sprint. The effort is estimated in comparison to the work already done by the team and the stories delivered. A good velocity therefore provides as good a forecast as possible.
The unit are story points. Each team chooses different stories for comparison. A story point means completely different things for different teams. So you can’t compare velocities. However, teams are sometimes praised for their higher velocity. In these cases there is a simple way out: The capacity per sprint can be doubled by doubling the story points of each story and the velocity. Or you can simply use numbers in the range of some Googol or Googolplex to estimate and achieve an almost unbelievable speed. Of course, nothing has changed, the predictability is still the same, but the nominal velocity is significantly increased.
Now terms are just terms. But they are also metaphors and shape thinking. The original terms Scrum, sprint, and velocity come from a stressful, highly competitive environment. They don’t stand for trust, and collaboration. But they can be seen as indications of higher speed and productivity. The desire to achieve better productivity is an important motivator to improve.
But these associations lead to problems, because instead of the values from the Agile Manifesto, productivity is suddenly the most important. And this leads to a misunderstanding of a central concept, namely agility. Agility refers to the ability to react flexibly to changes. Agility can also be interpreted as high speed and high productivity. But this can only be reconciled with the agile value of respect for the individual if it is clear that higher pressure does not lead to better productivity. Otherwise this misunderstanding leads to a perversion of agility. But unfortunately Scrum’s metaphors make it attractive for people who expect a competitive advantage from agility and are not only used to pressure, but sometimes see it as an opportunity to achieve their goals.
Scrum as a Product
Scrum is also attractive for other reasons. There are numerous certified Scrum Master and Scrum trainings. This facilitates the implementation of Scrum and is certainly an advantage. But it can also go wrong. The product “Scrum” doesn’t seem very complex: There are only a few rules and roles. If all these rules are followed, then you seem to be agile. But agility, according to the Agile Manifesto, is a set of values. Implementing values actually means a change in culture. This is anything but easy and hardly achievable by buying a product. Thus a transition to Scrum might uses the practices, but might still perverts the values.
In addition, the concrete Scrum practices can obscure the view on the improvement of the process, because everything is already defined. These improvements are an important part of agile methods. But of course Scrum can be a good starting point to implement agile values, if you use and improve the practices accordingly.
There are also other approaches in the agile world. Extreme Programming (XP), for example, puts development in the foreground. “Customer involvement” and “no overtime” are Extreme Programming practices, so some agile values are translated directly into practices. As a metaphor, the term “extreme programming” certainly does not stand for higher productivity or other things that promise a competitive advantage and is therefore not attractive for some target groups. Extreme programming as a term seems to stand for unstructured coding and hacking, but in reality it is a very regulated process in which practices must be implemented in a disciplined manner. So also the metaphor “Extreme Programming” has some problems.
“Developer Anarchy” is not only much more aggressive in its metaphor, but also in its approaches.
Between the very ceremonial approach of Scrum on the one hand and the disciplined approach of Extreme Programming on the other hand, there are also the Crystal methods. These methods are characterized by a few basic rules that are strongly oriented to the values of the Agile Manifesto and focus on human interaction. To prevent the blind implementation of potentially inappropriate practices, Crystal relies heavily on creating a lived process for each project, reflecting and adapting it to the needs of the current situation.
In doing so, the modular principle can borrow elements from other approaches to create a suitable process model. This prevents the slavish implementation of a process. These freedoms can, however, ask too much of some teams, which in turn can lead to less agile and more static processes.
The terminology of Scrum such as “Scrum”, “Sprint”, “Speed”, or “Velocity” creates associations that hardly fit the agile values, but promise higher productivity. Therefore, they are attractive for certain target groups, but unfortunately perhaps for the wrong reasons. Extreme Programming and Developer Anarchy represent an alternative to this, which places the coding in the foreground, but also implements some agile values directly. Often Scrum is misunderstood as a product and a fixed process, a customizable set of practices like Crystal focuses more on an adaptation of the process from the beginning.
However, despite all criticism, the adaptation of a clearly defined process like Scrum can be a step in the right direction and Scrum can be a good basis for agile software development. Nevertheless, one should be aware of the challenges.
Many thanks to my colleagues Tobias Erdle, Robert Glaser, Markus Harrer, Hanna Prinz, and Sonja Scheungrab as well as Tanja Maritzen for their comments on an earlier version of the article.
Many terms and metaphors from the agile world lead to associations that hardly correspond to the agile values.