There are many good reasons to consider agility. For instance, you could believe in the largely untapped creativity, motivation and self-responsibility of employees. Or you could recognize that a plan-driven approach to tackle complex problems is less suitable than an empirical one. And, of course, you could have the desire to radically focus on customer value and optimize the value stream accordingly. However, if you prefer to stick to the old ways of thinking, you certainly should avoid these considerations. Instead book titles such as “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland (a book worth reading and helpful by the way) lead to a fatal fallacy: Agile methods are sort of concentrated feed that will boost the performance of your employees.
User Stories are maybe the best known concept from agile software development. Unfortunately it is also one of the most misunderstood concepts. Let’s clear up the three most common misconceptions: User Stories are not part of Scrum, they are not tiny specifications and it is not the product owner writing them.
In order to understand agility from a historical perspective, it is important to go back to the principles of lean management. Agility in the sense of the Agile Manifesto from 2001 can thereby be seen as the application of the five principles of Lean to software development. The focus of agility is on the rapid delivery of customer value through working software. And the optimal flow for this comes from an interdisciplinary and self-organizing team that covers the complete value stream from the idea to operating the software.
In most hierarchical organizations the spirit of absolutism still prevails. All power is with the boss. He or she manages and controls, imposes rules, monitors their compliance and punishes misconduct. Even today there are still enough small and big Sun Kings: L’état c’est moi! This is because people are still susceptible to excessive power on the one hand and on the other because the Enlightenment apparently had little influence on the design of modern organizations. The advance of knowledge work and the increasing striving for agility also lead to a new Enlightenment with a more pronounced separation of powers.
Scrum is a deceptively simple framework for agile product development. Besides the development team there are only the roles Product Owner and Scrum Master. The process is lean and requires only a few artifacts and events (as the meetings in Scrum are called). This simplicity leads in practice to all kinds of fake agile and cargo cult – lovely but rather ineffective drama. To prevent this from happening, there is the Scrum Master. Unfortunately, this important role suffers from many misinterpretations, as the following three anti-patterns illustrate.