Democracy and Scrum
Modern democratic countries have a common model that separates main powers. Political power is distributed into legislative, executive and juridical. This intentionally puts institutions in a configuration in which they control each other and have the chance (and obligation) to challenge each other. But at the same time, they need to be in synergy with each other in order to ensure success. The reason for this separation is clear – by definition “power corrupts”, so we should avoid letting too much of it concentrate in a single entity. On the other hand, unchecked power does tend to concentrate and aggregate, unless there are forces preventing it from doing so.
And even though democracy is far from perfect, leaving aside any political views and agenda, there are some good ideas about distribution of power within complex systems. We can borrow and use them in the smaller scale of our teams, which are also happen to be complex systems. Systems that work well all have mechanisms for self-control, feedback and power-balance at their core.
And indeed, believe it or not, a similar smart self-balancing mechanism is built-in into Scrum itself, but sadly, it is often overlooked in practice and even in literature. In the real world, this mechanism is often butchered to no end – key institutions are represented only formally. The result is power imbalance, which often leads to implicit conflicts of interest that can slowly but surely cause trouble and derail an otherwise perfectly capable and competent development teams.
Main Powers in Scrum
So which are the main institutions in a good implementation of Scrum and what are they mostly focused on? You have the following 4 key institutions with different interests, applying their own force on the system:
- The Product Owner – an institution representing mainly the CLIENTS
- The Scrum Master – an institution representing mainly the PROCESS
- The Team Manager – an institution representing mainly the PEOPLE
- The Team – the society – an entity that all aforementioned institutions are meant to serve. Representing the product and technology knowledge
The main point I want to make is that you need to have all these roles represented strongly and explicitly in a balanced model if you want it to be capable of self-balancing.
To illustrate the idea better, I like to draw these as forces pulling on a parachute I call the “Scrum Power Parachute”. This parachute will work as intended and open properly, only when all the forces that are pulling in different directions, are also relatively equal in strength and act together. Having forces that pull too strongly will rip the parachute apart, and having them pull weakly or in unbalanced way, will result in the parachute not opening at all.
So, these institutions, all pull the system in the direction that they represent. In a normal environment you will have these institutions in a constant love-hate relationship, that would result in proper balance – people that are happy, clients that are happy, and a well implemented process that works alright for all actors involved. Each of these institutions will need to compromise here and there and that is OK – this is exactly the way the complex system is supposed to work.
All that being said, these institutions do have the same ultimate goal (a democratic society has common goals, too). They all want to deliver results and do so in an efficient manner that makes everyone happy. So it’s natural that roles of different actors within these systems would overlap here and there. After all, everyone benefits from working with happy employees, happy customers and good processes. So it’s common for actors to support each other in these common goals, even though they might not be the ultimate decision makers or responsible parties for the particular goal.
Common power distribution anti-patterns
Anti pattern 1: Wearing multiple hats at once
In practice, you’ll sometimes see the same person executing two or even all of these roles. I’ve seen implementations in which even a person from the team itself is executing the Scrum Master role in a “by-the-way” manner. There are even some extreme cases where one person represents Product Owner, Scrum Master and is an active hands-on team member. While this might work in very simple scenarios and products in a very initial stage, such an approach is unsustainable in the long term and would cause all kind of unpredictable imbalances.
I’m not arguing that there is no possible way for a single person to perform well in all these roles at the same time. However, I believe this is extremely hard to pull off and requires quite a bit of experience and thought. Executing multiple roles and doing it well, means you understand in depth all nuances of these roles. I, myself, have been in this situation for a while, and let me tell you that I thought this was the closest thing to schizophrenia that I’ve ever experienced. The amount of context switching was enormous and I felt like the main character in “The strange case of Dr. Jekyll and Mr. Hyde” novel, even though I believed I knew what I had to do rather well.
There is another aspect to all this. In a more corporate environment that does regular, formal performance reviews, wearing multiple hats means you will need to have a very balanced set of yearly goals in place. These goals, must represent all the roles you execute and therefore they must complement and also contradict each other in some very sophisticated, yet clear ways. Otherwise, you’ll have to compromise between them in favor of the one with the highest priority and importance.
Here is what I mean. Take, for example the typical anti-pattern: the Team Lead who is also a Scrum Master and a Senior Developer all at the same time. As a lead, this person will probably have a goal of low employee turnover, and a goal of high employee engagement and perceived happiness. When confronted with a choice between facilitating a proper ritual on one side and doing what people want on the other (they might even want to stop doing planning altogether, because it takes time and is “boring”), a person with these goals, would rather opt for the popular decision of abolishing planning, just because it’s in sync with or his or her goals and incentives. After all, satisfied employees will bring you higher engagement score, and a bad process doesn’t directly harm these goals.
Building up on this example, imagine the person is in a senior developer role as well, and is running “a bit behind schedule” on a story to close a sprint. Of course, they will be more likely to cancel the retrospective for the team in favor of being able to work a couple of hours more. And I hope by now, everyone sees how this spells trouble.
These examples picture how unbalanced goals may cause quite a bit of problems when a person is put into a position to execute multiple roles. And now ask yourself: how many people in this situation do receive well thought out goals that really address the above concerns?
Anti Pattern 2: Overruling someone else’s decisions
Sometimes team members will take a prioritization decision by themselves, or they will simply ask the Team Manager or the Scrum Master to reprioritize things. This might mean that the product owner is not well-recognized and this can lead to problems. To prevent such occurrences in the future, they must be resolved on the spot by redirecting the person to the decision-making party, no matter how obvious the resolution might seem. This builds the habit of always making sure the order is followed.
Everyone involved should know what all the roles represent and what are the areas in which they are the ultimate decision makers. For example – the Scrum Master would make the final call on everything regarding rituals and the process, while the Product Owner will be the person to ultimately decide if something has high priority or not. These institutions can still influence each other, the team might also influence them, but no one is allowed to overrule the decisions in someone else’s domain.
So, be on the lookout about who makes the final call and address inconsistencies right away! Educate team members on who owns what. Resist the temptation of making someone else’s decisions when they are not in the room. It does take time for people to get used to some things. For example, that every question regarding priority needs to go through the Product Owner. But the effort is worth it eventually. I promise.
Anti pattern 3: Extreme bias toward one institution
Does your implementation have extreme bias towards client satisfaction while paying the cost with low employee engagement and happiness? Or are you’re in the opposite end of the spectre – trying to make your Scrum process perfect and people happy, but often failing to meet clients expectations?
If you are in these or in another similar case, you most probably have problems with power distribution. This might be due to some of the power representatives being too aggressive, too mellow, overly assertive or just inexperienced. You might also have problems with how goals for these roles are being set. Sooner or later you’ll need to address the causes if you want your Scrum process to balance itself out as intended.
Thanks for reading this article! I hope you found it thought-provoking and I’ll be happy if you share your thoughts and experiences.