What a makes a GREAT scrum master?




Part time scrum master?

Many software teams who claim to be "doing scrum" have people “stepping into” the role of scrum master.
I frequently see project managers, development managers, testers, developers taking the reins with varying degrees of success. Often, willing team members take on the role of scrum master in addition to their development or testing responsibilities! I also see a lot of teams going solo, i.e. doing scrum without a scrum master. This is a practice that I think ultimately prevents a team from improving and getting full benefit from the scrum process. Even if someone possesses all of the soft skills to the do the role, they still need to have the core skills and knowledge required to be an effective scrum master.

The scrum master responsibilities

  • Be the Guardian of the scrum process
  • Be a servant-leader to the team
  • Be an impediment remover
  • Be an interference shield for the team
  • Be a coach
  • Be an agent of change
I don't think that a part-time or temporary scrum master can fulfill all of these responsibilities and to do this role successfully you need to be all of the above things to the team. I think that someone who steps into the role can be a good scrum master, but will they be a great scrum master?

Two levels of scrum mastering?

I think there are 2 levels of scrum mastery.

Level 1: B.A.U.

This is the layer of scrum mastering that keeps a team ticking over. The part-time or temporary scrum master tends to operate at this level. The list of responsibilities include (but are not limited to):
  • Be the Guardian of the scrum process
    • Ensure PO has a backlog of stories for the team to work on
    • Ensure PO has prioritized a list of stories before planning
    • Ensure the team is clear about the requirements
    • Encourage the team to make a projection of the amount of work they can achieve in the sprint
    • Ensure team feels comfortable with projection versus current velocity
    • Protect the sprint backlog
    • Limit W.I.P.
    • Ensure the team focuses on quality
    • Monitor the stand up (make sure people don't waste time, keep updates short, stay on topic)
  • Be a servant-leader to the team
    • Set up all scrum ceremonies
    • Point of contact for Scrum updates.
    • Send out reports/ burn-up charts
  • Be an impediment remover
    • Remove barriers to productivity
    • Help to resolve issues/ arguments/ debate
  • Be an interference shield for the team
    • Maximize time available for developers to develop (protect dev time )
    • Reduce waste/ non sprint activity
    • Protect team members from being dragged away to work on non-sprint activities
    • Protect the team health and well being

Level 2: Strategic

This is where all the good stuff happens. A full time, "proper" scrum master will operate at this level.
  • Be a coach
    • Help team to self organize
    • Help the team to improve engineering practices so that each sprint/ story is potentially deploy-able
    • Help the team understand Scrum/ agile principles and techniques (rather than just mindlessly following a process)
    • Help the team understand the benefits of these techniques
    • Help the product owner manage the backlog
    • Remove the distance between the PO and the team
    • Teach the PO how to maximize R.O.I. and meet objectives through SCRUM
    • Ensure the team is learning in retrospectives
    • Promote continuous improvement
    • Coach a team to self sufficiency (e.g. how to remove own impediments)
  • Be an agent of change
    • Observe & identify areas for the team to improve
    • Create a culture of continuous improvement in the team
    • Facilitate creativity and empowerment
    • Determine where the Scrum process is compared to where it could be
    • Potentially look beyond scrum, for techniques that can help the team improve (e.g. Lean/ kanban)
    • Challenge the team to improve engineering practices (CI, TDD for example)
    • Look to improve things outside of the team that are slowing the team down (e.g. business stakeholder involvement, handover to dev ops, poor communication across the organisation)
    • Keep an eye on the future 

High performing teams through great scrum mastering

The scrum master who operates at the strategic level will give teams a massive boost over time. To have someone who is focused on improving a team and making a team awesome and improving a team's working environment means that inevitably, positive change will occur within a team. The alternative is stagnation. 

If your team has a level 1 scrum master or worse, no scrum master at all, who is going to constantly beat the drum for improvement? who will keep an eye on the future and the health of your scrum process? Who will promote constant improvement? Who will ensure the team is always learning?

In my experience, having a great scrum master with a strategic remit, facilitates the growth and nurturing of awesome, productive, high-performing teams. This stuff doesn't just happen!





Comments

Post a Comment

Popular posts from this blog

Expanded EPIC boards

Image
What's the problem? As scrum teams, we always look to the Product Owner as the fountain of all knowledge and requirements with respect to our supply of work. Yet, I've found that often the big ideas or concepts for projects are so light on detail that POs are desperately in need of a way to translate the high level idea into a backlog of stories to get the dev team up and running We've all been part of projects where the BAs and POs lock themselves away for a few weeks with a high level understanding of a project and come back with a list of user stories for the dev team to work on. By the time the devs see the requirements, its hard to see the wood for the trees. We get bogged down in the details, the stories are sliced poorly & are not delivering vertical slices of functionality. Often there's no wiggle room. Its all MMF. We cant cut anything out. Additionally, defining an entire release worth of stories in advance which, ultimately, require change or may
Read more

Things to consider when you want to change from Scrum to Kanban

Image
Scrum or Kanban? A common problem with agile teams is whether they should choose Scrum or Kanban as their primary methodology. Scrum is the usual starting point for most teams and the current market forerunner when it comes to selecting your agile weapon of choice. According to the 13th State of  Agile report 54% or teams surveyed claim they are using Scrum, with a further 10% claiming they do a Scrum/ XP hybrid. Kanban trails behind at 5% with Scrum-ban hybrid adding a further 8% "Scrum doesn't work for us!" I often hear teams saying that scrum doesn't work for them. When I ask "why?" I usually hear the following: We can't finish anything in a 2 week sprint There are too many meetings Our list of priorities keeps changing We can't plan for 2 weeks.  Our product owner keeps changing his/her mind They often feel like Kanban is a silver bullet because: It doesn't ask you to finish anything in 2 weeks It doesn't im
Read more

Moving beyond tasks

Image
One of the most common agile anti-patterns I witness is a compulsion towards breaking user stories into tasks. Tasks take focus away from stories The problem with tasks is that they take the focus away from user stories. Teams that focus on completing tasks risk losing sight of the real value which lies in the stories. They are often unable to see the wood for the trees. How often have you seen sprints that are? •             On day 9 of 10, but <30% of story points are complete •             On day 5 of 10, but <10% of story points are complete •             On day 9 of 10, with 90% of tasks complete, but still <30% of story points complete I firmly believe this is a by-product of too much focus on tasks and not enough focus on stories. Tasks themselves add little or no value on their own. I often see tasks such as “Manual QA”, “Code Review”, “Write test cases”, “Database work”, “Front end work”, “Back end work”. People often argue to me that the task breakd
Read more