Separation of Power in the Scrum Framework
As delicate a balance in Scrum as it is in our democratic institutions
Among the many smart ideas used in the Scrum Framework, my favourite is the way the three roles (since 2020 known as accountabilities) separate the responsibilities of the Scrum Team:
Product Owner: responsible for the what,
Developers: responsible for the how,
Scrum Master: responsible for the Scrum way of working.
The Product Owner decides what needs to be done, the Developers decide how to develop it, and the Scrum Master helps everyone to continuously improve the way they use the Scrum Framework to carry out their responsibilities.
I think it is the balance of these three things that make Scrum Teams so effective.
The way I’ve seen this unfold in the teams I’ve worked with is that the Product Owner is driven by the needs of the stakeholders, who naturally want everything yesterday, preferably as cheap as possible. The Developers are masters of their craft and are driven by the pursuit of perfection. This creates a tension that ideally brings out the best possible compromise. I use the word ideally intentionally because of course, the line between tension and outright conflict is thin. This is where the Scrum Master comes in, driven by the need to make the team effective, and thus continuously coaching both parties on how to resolve this tension.
To me, this reflects the way power is balanced in many forms of government, the trias politica, in which legislative, executive and judicial powers are separated into independent bodies.
There is no attempt here towards some kind of moral resolution, but simply a clear understanding and acceptance of human nature, and how best to pragmatically make use of it. As Immanuel Kant put it:
“the problem of setting up a state can be solved even by a nation of devils so long as they possess an appropriate constitution to pit opposing factions against each other”
And this, in my opinion, is precisely what the Scrum Framework does too, pitting the three opposing accountabilities against each other to create a balance. To think that such a simple idea could lead to such a far-reaching balance.
This is a typical characteristic of the Scrum Framework. The rules seem arbitrary and simple, but they all contribute to a delicate balance. And this, I think, is the reason why the Guide explicitly tells us that you must include all parts of Scrum for it to be Scrum:
While implementing only parts of Scrum is possible, the result is not Scrum.
Conclusion
Talking about the balance of the accountabilities, I realise that this also illustrates why the Scrum Values are so important. It is only with Respect and Openness that all three accountabilities can Courageously Commit to their own accountabilities, safe in the knowledge that however heated a situation may become, there is always a shared mutual understanding, a Focus on a beautiful synergy.
In fact, I find this to be such a powerful mechanism that nowadays, wrestling with the subject of scaling, I wonder if it could be applied more broadly. If we agree that scaling can be viewed as the evolution of a hierarchy of levels of detail, I wonder if the same separation of power could be created at the levels above the team.
For example, imagine the super-Product Owner we see in most scaling frameworks, the guy who does the epic-level planning before it is passed on to the Product Owners in the Scrum Teams.
Imagine someone like an IT manager, someone to represent the Developers’ quest for quality, but at that higher level of detail.
And imagine an Agile Coach or Senior Scrum Master working with them, mediating in their collaboration and ensuring that they stick to their allotted level of detail.
I am left wondering whether Jeff and Ken actually had this mechanism in mind when they created the Scrum Framework, or whether it is something that just happened by accident. Whatever the case, to me, it is a beautiful thing.