What NOT to do as a Scrum Master

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.

What NOT to do as a Scrum MasterSometimes, 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.

This might be interesting: Say no more “Buts” and stop asking yourself why Scrum is not working.

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?  

What NOT to do as a Scrum Master

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.

Read as well: 5 keys you can’t skip on your Agile process

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

What NOT to do as a Scrum MasterI 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.

Content Related: Agile Management: 5 Scrum Myths to see closely.

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, bad 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.

White Paper

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.

RECEIVE OUR NEWSLETTER!

Share this articleShare on LinkedInTweet about this on TwitterShare on FacebookShare on Google+Email this to someone
Go Back