Stuff I learned working as a scrum master

 

Working as a scrum master I learned a couple of hard truths :

• People have a lot of misconceptions about what a scrum master should be doing
• Sometimes they are true (which makes things worse)

Now If you take a look at the Scrum guide the scrum master has a lots on his plate:

Now the things I most often hear is that the scrum master should:

• make sure there are burndown charts (as the single most important thing a scrum master does)
• organize and run the scrum events (although the guide says that the scrum master should be doing that as needed or as requested)
• remove impediments

I’ll be honest, in relation to burndown charts I never drew one (there are tools for that). I find that tiring and I think there are better uses of my time. But surprisingly this is what I most commonly hear from developers – “My previous scrum master was spending most of his time drawing charts and organizing meetings …..” – what?

Scrum events are important but the thing is that the value of a scrum event is not provided by a scrum master but by the people joining the event. I think that helping people to prepare for the scrum event is much more important then actually running the event it self. I rather focus my self on facilitation then on meeting organization.

Removing impediments its a very important thing. The team has bring business value by working on the sprint backlog as agreed with the product owner. Anything that is preventing the team to do that must be ruthlessly removed.

Now here lies the catch. That could be a wide variety of things. And is really contextual – what is the current situation within the team and the company dictates what is an impediment and what is a possibility to grow.

In situation A the team needs to build a MVP (Minimal Viable Product) to put on the market as quickly as possible. Anything preventing the team to the most important tasks to achieve that is an impediment ( I try to simplify things as much as I can). Now in that situation building a continuous integration server , something the team has no experience with , or making sure all resources on Azure are created as they should or taking care of 3rd line support calls coming to the team or helping write all the unit tests or doing some research or … the list could grow. And all those things could also be things the team could be doing and taking them as learning and growing opportunities.

Its highly contextual.

Now for me the rule of the thumb is as follows:

• Is it part of the teams core skill set – yes (let them do it)
• If not is it needed to achieve sprint goal – yes (ok deal wit it somehow)
• Is this the right time to grow the team on this skill – yes (let them do it, and help them)
• If not take care of it your self or find somebody who will