When it comes to agility, many people think in terms of methods such as Scrum on a small scale, frameworks such as LeSS on a large scale or tools such as JIRA. This perspective leads to a multitude of cargo cult, i.e. artfully celebrated actions without any effect. Agility is first and foremost a question of stance, which is best captured by the notion of sailing by sight. While classic plan-driven companies always strive to analyze, plan and then implement as comprehensively as possible, agile companies pragmatically ask themselves periodically what they can do here and now to improve and further develop their product.
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.
Successful agile organizations are strongly oriented towards a common mission despite the guiding principle of self-organization. Autonomy requires orientation, otherwise it leads to chaos. Of course, all other organizations also claim for themselves an appropriate vision and mission. Agile organizations, however, are more impact-driven. They focus more on outcomes and measure the impact that these outcomes make. Traditional organizations are more input-driven inasmuch they try to plan exactly which input in terms of resources is needed