While Scrum is a very flexible practice, there are certain limits that must be taken into account. Read here 5 things a Scrum Master should NOT do.
Scrum is an Agile framework with simple and non-prescriptive practices. As such, many processes are left to interpretation and are adapted to the context of the project. However, there is a caveat to this freedom, as many times the Scrum Master may lack experience and might impose some bad practices on the team.
Thinking about taking advantage of all of Scrum’s strengths, here we review 5 of those mistakes a Scrum Master must avoid.
1. Imposing processes and practices
Scrum leaves a blank space to be filled for most practices, which is why Scrum is adaptable to many scenarios, industries, and companies. These practices and processes are usually completed by jurisprudence of the industry: That is, best practices are picked by the team and Scrum Master that are considered best for the project.
Sometimes, the Scrum Master might pick and impose those best practices –to the best of his/her knowledge– without consent of the team. In some cases, this might work (which is actually dangerous as it sets a bad precedence), but other times, the team might not adapt well to that way of working or might even rebel against this imposition if the practices are not well selected.
Since Scrum is not prescriptive, the Scrum Master shouldn’t be either. Remember, the Scrum Master is not a tech lead or PM but is the person responsible for making sure that Scrum is correctly applied and that the processes are shaped and adapted to the project in its present state.
2. Give a man a fish and you will feed him for one day…
Part of the role of the Scrum Master is to be a facilitator for the team. Another common mistake made by Scrum Masters is solving the impediments for the team, instead of assisting in doing so.
Of course, occasionally the Scrum Master has to get involved in solving some issue –that is why it is important that the Scrum Master is given the authority in the company to do so. Nevertheless, in most scenarios, the Scrum Master should try to avoid getting directly involved in the solution and instead guide, suggest, and propose the solution to the team or Product Owner. They should be the ones to carry it out.
Next time the team struggles with a similar problem, it is likely that they will be able to figure it out by themselves.
3. The Scrum Master should not take sides
The facilitator role of the Scrum Master means that in a situation of conflict, he should not take sides or have any predilection for someone’s opinion. Instead, he should serve as a mediator in helping the parts reach a solution. That is why we always say that the most important tool of the Scrum Master is asking the following question: Why?
Many times, just by asking why to the team is enough to get them to reach a solution or find the root cause of a problem. It is an effective way to serve as a mirror to reflect the situation to the team, which is the first step to self-improvement.
A teacher once told me that the Scrum Master should behave like a fly on the wall, always watching and alert, but only getting involved when necessary.
4. Overcomplicating or oversimplifying the processes
Scrum is all about adaptability. In order to adapt, you need to start simple and add complexity and mature practices as the team also matures. Even though the Scrum Master and the team need to interpret Scrum and apply jurisprudence with good practices, a Scrum Master should not try to apply all of them on Sprint 0.
Start small, but think big, and aim high.
On the other hand, do not oversimplify or loosen the practice of Scrum too much. Yes, it is adaptable, and yes, it is flexible, but that does not mean allowing daily meetings of 30 minutes every now and then or that a Story can be marked as Done when almost done.
Once you set up your practices, follow them and respect them. If they seem too restrictive, or that they do not apply any more, do not just ignore them – modify them.
5. The broken telephone game
I have seen this often enough: The Scrum Master is used as the sole point of contact between the team and the PO or other stakeholders.
Not only is this wrong, but the quality of communication also gets affected by the entropy of having one person communicating everything back and forth. We already have that issue with the Product Owner and the other stakeholders; we don’t need more!
As we mentioned before, the Scrum Master should facilitate but not resolve. If the team cannot get hold of the PO to get answers on the User Stories, then the Scrum Master should help the team solve this issue but not by getting the answers himself/herself.
Remember that the Scrum Master requires a level of authority, and without it, there are impediments that he/she won’t be able to help resolve, which beats the purpose of the facilitator.
To sum up
The Scrum Master takes on many roles in a Scrum project. Sometimes it might even take on the role of a tech leader, an architect, or even a developer. However, a good Scrum Master should know which hat to wear in which situation.
A good Scrum Master is a facilitator, mentor, coach, mirror and news messenger, and mother-in-law (always highlighting the flaws), but he/she should always behave in a way so that the team and PO improve their processes, show professional humility, and try to reach the unreachable utopia of software development perfection.