Anyone who imitates Spotify or introduces SAFe or obtains imitated or falsified agile frameworks and disseminates them as best practice will be punished with futile ritual practices of not less than 20 hours per week and employee. The way into the agile cargo cult hell is well paved with best practices, blueprints and frameworks and is bordered by billboards saying: “Don’t invent the wheel again!” Agility, however, is less a question of methods than of principles and stance.
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.
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.