Is Your Scrum Master Making These Mistakes?

Carl
Carl
Aug 26 · 4 min read

At NONA, we pride ourselves on a fluid and tight-knit team dynamic. It’s hard for our developers to maintain velocity consistently without our Scrum Master, Mr Miyagi Brandon Seymour being at the top of his game. How does the man with the plan avoid a development train-wreck? Read on…

You’re there to serve

The biggest mistake a scrum master can make, at any point, but especially when joining a new team, is not listening. It’s vital that a scrum master listen first, gain rapport with the team by asking questions and understanding, and only then suggesting changes or more efficient ways to do things.

A scrum master isn’t ‘the manager’. It’s up to the SM to guide and coach the team, not dictate process and tell everyone what to do. Alignment — not management. An SM should aim to build a strong, self-organising team, and ultimately, should aim not to be needed.

Closely related to the above is to refrain from trying to make big changes off the bat. Rather, implement small, relevant changes first, and allow the team to see the benefits and gain your trust. Generally speaking, developers aren’t huge fans of process. However, if they see the process as valuable and useful, they’ll be more adaptive and keen to jump on board. For example…

If morning stand-ups are taking longer than the allocated 15 minutes and the team is sitting down and chatting for too long, a small change would simply be to ensure the team is actually standing. Time and again we prove to ourselves that these meetings move more fluidly when people are on their feet. Another way to enhance fluidity would be to remind the team of the YTI rule. YTI = Yesterday, Today, Impediments. In other words, what I did yesterday, what I’m doing today, and do I have any impediments to progress? Small changes make it easier for the team to get into a rhythm and effectively run the meeting on their own, rather than relying on the SM to do it.

Of process and performance

There are many good processes that come out of the scrum textbook. Most of these are relevant and necessary. However, they’re less valuable if the underlying principles aren’t understood. It’s critical that everyone understands why things are being done. For example…

Backlog grooming is a process whereby the team will run through a number of stories in the backlog with the product owner. The PO will run the team through the acceptance criteria and requirements, and once this is done the team is required to give an effort estimate. Quite often the team doesn’t understand the reason for assigning what they consider a random number to a story, but there are a number of important ‘whys’ involved here.

  • This ceremony allows the team to provide story points, which when combined with their velocity, can provide a fairly predictable delivery date. This is preferable to a delivery date dictated by business or marketing
  • By using the above measurements the SM and team are easily able to communicate progress or any potential delays
  • It allows the team to understand and visualise the work that is to come
  • It provides the team the opportunity to start discussions and planning on how to tackle the work technically
  • The ceremony also allows the team to discuss any questions or concerns with the PO at an earlier phase, therefore allowing for agile changes to be effected sooner

Work with your business, not against it

No development team should ever see the product owner or business as the enemy. The strongest teams are the ones that have a great relationship with their PO, and a good understanding of why businesses make certain decisions. The product owner and the scrum master should work like a mom and dad :-)

Finally, try not to over complicate processes and principles. Keep it simple and keep it clean. Ensure requirements are clear, and that the team is prepared and understands how to tackle the work technically. No two teams are the same. As a scrum master, never assume that what works for one team will work for another. Teams, like individuals, are all different. Be flexible with what you know works, and you’ll be a Mr Miyagi in no time!


NONA is a cutting edge software development studio. We build beautiful, scalable software that gives our partners a distinct competitive advantage. See who we are and what we stand for here.

NONA

We are a leading software development studio focussing on Fintech, Blockchain and Logistics. Contact: studio@nona.digital

Carl

Written by

Carl

NONA

NONA

We are a leading software development studio focussing on Fintech, Blockchain and Logistics. Contact: studio@nona.digital

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade