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.
Originally, court jesters were not entertainers or jokers, but serious characters. They had an important task and were an integral part of the court. Their foolishness, however, relieved them of the social norms and allowed them to express grievances and (religious) misconduct in a more or less subtle and humorous way, thus inspiring the authorities to reflect and rethink. Because of this “fool’s freedom” they were a social institution of permissible criticism. The separation of powers in agile organizations means in the last consequence also a renaissance of this venerable social institution of the court jester in person of the Scrum Master.
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.
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.