There is a fundamental misunderstanding around agile. This misunderstanding begins with the title of the Manifesto for Agile Software Development. For too long, many considered software development to be the translation of specifications into code by interchangeable programmers completely disconnected from their customers and their products (and often reinforced by contracts). And this is exactly what many still understand by software development nowadays. Only in shorter cycles. Simply agile. But the authors of the manifesto, all passionate software developers, were concerned with something else. They tried to put software development back at the core of value creation and to eliminate all the waste around this core, all the heavy-weight processes and their manifestation in organizational structures. Their aim was to build software as a long-lived team really owning the product. And there must be no middlemen between team and customers with corresponding artifacts and handovers. Instead, business people and developers must work together on a daily basis to explore the market, the product and the solution space together.
One of the four main propositions of the Manifesto for Agile Software Development is “Customer collaboration over contract negotiation”. And then one principle behind the manifesto say: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This notion of the customer unfortunately often leads to what Jeff Patton calls the customer-vendor anti-pattern. Especially in large organizations with their own IT departments, this pattern occurs when the Product Owner understands his role as a representative of internal customers and submits requirements to the Development Team for implementation. Understanding customers and their needs is important, but it is only one aspect to make a product successful and exactly that is the task of the product owner. In order to cover all aspects, the Product Owner must not be an ingenious and lonesome decision-maker and not be unilaterally associated with the business, but rather the leader of a team of experts who together take responsibility for the sustainable development of a successful product.
When it comes to agility, most people think of Kanban or Scrum at the team level. And then of course the many scaling frameworks come to mind like LeSS, SAFe, DAD or Nexus. These frameworks primarily address the question of how the work of several or many teams on one or more products can be coordinated and synchronized. Especially in legacy IT landscapes with many dependencies this is a legitimate and frequently asked question, which unfortunately often obscures the far more important question of decoupling, but that is different story. The focus will now be on the question of how to give agile organizations alignment at different flight levels with corresponding planning horizons. And to this end, it is important that strategy remains an empty sphere of action that is filled with content from bottom to top.
Copying Spotify or simply implementing any other blueprint of an agile organization is a fundamental mistake. Not because the models themselves were poor, but because implementing a model of an agile organization that has been chosen or developed by a few managers, experts or consultants from top to bottom contradicts the essential principle of self-organization. Agile organizations are always emergent in the sense that they result from the cooperation of self-organizing teams towards a common vision and are constantly evolving. Therefore, it is crucial for a sustainable agile transformation to withstand the pressure to deliver short-term successes and to empathetically and confidently give people the space and time to learn and grow together. As tempting as blueprints and their large-scale implementation may look, it is precisely this that leads the agile transformation into a dead end.