I have been contemplating the role and capacity of the ScrumMaster for some time now and wanted to pen something down before my elusive memory fails me again.
It seems that there are a lot of confusion and misconceptions on the activities and capacity of this specific and important Scrum role in the industry. This paper will try to alleviate some of these concerns.
Typical Scrum Team
In my current position as ScrumMaster at Fundamo, I am the “servant leader” for over 2 development teams. There are about 7 developers per team of which one is a tester, and one is an architect specialization.
Where it comes to Agile maturity these teams score quite high (8 out of 10) as they have been exposed to a true Agile environment, mostly due to our Agile evangelist and Development Manager, Karen Greaves. When it comes to technical maturity, we do not score that high as we have been employing some new graduates and junior developers for our teams. The product that we develop is on face value not that complex, but when it comes to implementation and architecture it is quite complicated, and it takes some time before new people gain sufficient domain knowledge to be truly productive.
Given this information and looking at my attached mind-map image of the activities of a ScrumMaster, would you say that my days are fully occupied by these activities? Hopefully… yes!
The questions I like to put about the ScrumMaster role, and his capacity is more related to an idealistic environment where Scrum knowledge and implementation in the teams are closer to a 10 out of 10 and where you deal with technically very mature teams as well. I have 2 questions on the image sketched above.
- Is this utopian ideal a façade or can it be achieved?
- If achievable, will it make the work or function of the ScrumMaster redundant?
Let’s take the first question and have a closer look at it and see if we can make it stick.
Let’s say I am Mr Bill Ionaire and my resources are unlimited, and I have this super-duper product that I want to develop in an Agile fashion. Firstly I can recruit and head-hunt the cream of the crop with fantastic Agile and technical skills to develop this product for me.
As these teams are so well organised they decide that they do not need a ScrumMaster, but they will adhere to all other Scum rules, practices and events. They have agreed among themselves that they will make bookings in their calendars when the necessary meetings are held, and they will take it from there.
After a month and 2 sprints in the pocket, they have their second retrospective. The findings are:
|Delivered all committed stories||All Good|
|Establishing a good velocity|
|Getting to know one another well…|
What did they not say?
Chris who was a star at his previous company is now being outshone by some other senior developers and is not getting all the attention now that he was used to and is, therefore, losing his motivation. Mike is a bit of an introvert and is not speaking up easily and is, therefore, finding himself picking up tasks that he believes are inferior to his capabilities and he feels not as useful as he did before. Evan is the most outspoken and secretly thinks he is the star in the team, and he does not realise that other team members are becoming a bit irritated with his know-it-all attitude. Susan the developer who specializes in testing and love quality assurance, is, in fact, a genius and is also very frustrated as she believes the architecture is poorly designed, but she is afraid to speak up as she does not specialize in architecture and as a soft-spoken woman she feels a bit out of place to challenge the architecture.
This scenario above is already a shaken nest of hornets waiting to erupt. So looking more closely at the situation and also taking cognisance of the fact that the generation X and Y developers have a much higher tendency to leave companies than the baby boomers, we see that churn in Mr Bill Ionaire’s utopian company will also be unavoidable.
Where does it leave us with our questions regarding the ScrumMaster? All of the above issues were human related. The cost of gaining domain knowledge again, because of churn is human related. The result of not taking action on the scenario above will be devastating for the team. Either the team will magically resolve these human issues (very unlikely), or it will be bottled up and result in unpowered working conditions (demotivated team members) or resignations.
Besides the human factor, all sorts of other failings start to manifest in these teams. As the team starts getting less motivated, they lose their grip on the somewhat 36 Scrum rules. The biggest Scrum practice of self-organisation also begins to suffer. With all of this happening Bill starts nosing in the business of the teams to see what is going on, and why they are not delivering according to the previous velocity anymore. This in itself, disempowers the teams even further, and the negativity continues to escalate. What does this translate to for Mr Bill Ionaire?
- Less motivated team with serious issues.
A high churn in employees.
- High training and up-skilling costs in domain knowledge for new employees.
- Lower quality of software.
Divided work responsibility as
some members will inevitably have to do some of the ScrumMaster functions.
- Divided attention leads to less motivation.
Potential of unhappy customers.
- Loss of credibility and income.
ScrumMaster’s so called capacity
Truthfully, the ScrumMaster has the potential to hide behind process and not be effective as he can be, but true Agile teams will quickly expose these frauds.
A good ScrumMaster should run at full capacity. He is always endeavouring and looking for ways to make the team better. If it is not the case, it could mean:
- The ScrumMaster does not understand his role correctly and needs to get training.
The wrong person is in the
- Only Delivery Focus – This is a most dangerous position, as a person who is only focused on delivery and not the individual, will seriously harm the Scrum team.
- Does not like people – A ScrumMaster must “LOVE” working with people and get involved, if applicable, in team members’ lives.
- Laziness – The ScrumMaster role is a proactive role. Apathy could be a sign of not understanding the position, which might indicate further training or it could mean that this person is… lazy. J In this case, serious action should be considered.
Other reasons why SMs are need in mature teams
- The ScrumMaster is the valid instrument to encourage change; inspect and adapt.
- The SM/Agile coach creates value by just by being available. In the absence of SM, the team does not have a go-to person to sort out obstacles.
- Somebody outside the team is required to remove impediments. Team members cannot take on other soft and diverse tasks, which are not related to development. It is distracting, and they will lose focus.
- The SM is responsible for complete transparency in the team and facilitating all meetings and events.
- The SM needs to protect the team from unnecessary interruptions from POs and other stakeholders.
- The SM needs to motivate self-organisation at all times so that the team can become even more productive.
- The picture above depicts a team that has achieved a good level of Agile maturity over time. This team has three directions to go. Either they can continue bettering themselves; they can flat-line or go on the downward curve and decrease productivity. No company would want to jeopardise a good development team; therefore it is clear that to extract the SM (who had helped the team to get to this point) will undoubtedly lead to a downward spiral in productivity.
- In mature agile teams, the role and function of the SM are all the more important not only from keeping the team from regressing but also to further push for higher productivity.
- Another very important fact is that the SM needs to be involved in a continuous learning process, especially when the team becomes mature, as it becomes more difficult to achieve a higher productivity rate at point X. Therefore SM continuous improvement needs to be in line with the team’s improvement
So to answer the first question: “Is this utopian ideal of a perfect Scrum team a façade or can it actually be achieved?” The answer is “NO”. If one is saying “yes”, that person is also likely to say there are perfect people roaming the globe currently.
The SCRUM ideal is for one, a philosophy, as it pertains more to people than the actual technology developed. Moreover, if things can go wrong with people who develop this technology, you will never have that perfect Scrum team.
Moreover, to answer the second question… As we said this perfect Scrum Team is not attainable, it, therefore, follows logically, that a ScrumMaster will always be needed. Even if this Utopia was attainable; the amount of activities that the ScrumMaster gets involved in, scream out for a separate role. Developers will get hugely frustrated dividing and interrupting their workload with activities less technical belonging in the ScrumMaster space.
If any company, who has bought into Agile and Scrum, tries to run Scrum without a ScrumMaster, they are setting themselves up for potential failure.