Agility and Separation of Powers. Or: What Is the Boss Actually Doing?

In most hierarchical organizations the spirit of absolutism still prevails. All power is with the boss. He or she manages and controls, imposes rules, monitors their compliance and punishes misconduct. Even today there are still enough small and big Sun Kings: L’état c’est moi! This is because people are still susceptible to excessive power on the one hand and on the other because the Enlightenment apparently had little influence on the design of modern organizations. The advance of knowledge work and the increasing striving for agility also lead to a new Enlightenment with a more pronounced separation of powers.

Power tends to corrupt and absolute power corrupts absolutely.

Lord Acton

Agility is essentially based on self-organization. The principles behind the agile manifesto clearly state: “The best architectures, requirements, and designs emerge from self-organizing teams.” However, it is not only the work content that lies within the team’s sovereignty, but also and especially the organization of their work. As a reinforcement of this principle of self-organization, the next principle reads: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

The agile manifesto is radically non-hierarchical.

The agile manifesto with its principles is radically non-hierarchical. Scrum, as the best-known agile framework, does not introduce a hierarchy either, but gives the role of Product Owner as part of the Scrum Team the responsibility to maximize the value delivered by the Development team. In other words, the Product Owner ensures effectiveness, i.e. working on the right things, while the Development Team retains the freedom to implement those things appropriately. So the Product Owner determines the WHY and WHAT, the development team the HOW.

The Product-Owner as primus inter pares.

Even if it is occasionally said (not least here) that the Product Owner is the CEO of the product, this is not to be understood in an absolutist or hierarchical sense (The Product is Me!). Scrum hereby creates a role of equal value which leads the product in terms of customer value. The Product Owner may and will do this in close cooperation with the Development Team, because in the end this team must have understood the WHY and WHAT in order to achieve this desired value.

The Scrum Master is a servant-leader.

In addition to the Product Owner, Scrum introduces another role: The Scrum Master is the servant leader for the Scrum Team. He helps to optimize the collaboration within the team and between the team and the organization in order to maximize the value generated by the Scrum Team. The idea, however, is not that the Scrum Master acts like a project manager or teacher, but as a coach to support the team in its self-organization.

The boss unleashes human potential.

Despite all self-organization and freedom of hierarchy, arises the following question due to legal requirements: And who is the line manager? And what does he or she actually do then? Apart from formal administrative topics (vacations, illness, etc.) there is only one, but decisive task left. A task, which in the previous absolutist power was often neglected depending on personal inclination. And this task is to unleash human potential.

Leading means: serving life, eliciting life in people, awakening life in employees.

Anselm Grün

Now it seems straight-forward (at least in the previous absolutist logic) to make the Product Owner or optionally the Scrum Master the boss (or to give the former line manager one of those roles). Both lead to a clear shift of power in the direction of the respective role. In the most extreme case, not only the team, but also the Scrum Master is subordinated to the Product Owner, which would more or less restore the old absolutist power. In the sense of a good balance of power, I think it makes more sense to keep disciplinary leadership in the above-mentioned human sense separate from these roles and thus place a high priority on it. I would therefore even recommend that the members of one development team should have different line managers.

Stay Current!

You never want to miss an article on my blog again? With our Newsletter you will receive the latest articles in your inbox once a week.

Leave a Reply