No matter what you might think of Scrum, the Scrum Guide beautifully describes three aspects of leadership in the context of agile product development. At the center of value creation is the development team, which works autonomously and self-organizing. As the “CEO” of the product, the Product Owner leads the product and thus gives the autonomy a common vision and direction. And finally there is the Scrum Master, who serves the people and helps the product owner, the development team and the rest of the organization to work together effectively. A traditional manager is not described there, because his different tasks are distributed among these roles.
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.