Effective Facilitation as a Scrum Master
What is a Scrum Master anyway?
Scrum is hard. Well, the idea is simple enough: Make a plan, execute the plan, and inspect and adapt as you go. However, executing Scrum well is a significant challenge for many teams and organizations. While there are a number of factors that may influence whether or not a team is ultimately successful with Scrum, the effectiveness of the team’s Scrum Master stands out as perhaps the most critical. So, that said, what does a Scrum Master do that is so valuable?
The Scrum Guide defines a Scrum Master as follows:
“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The Guide then goes on to provide around a dozen examples of this definition in practice. While the examples range in topic quite a bit, you may notice some commonalities. Words like “helping”, “coaching”, “ensuring”, and “facilitating” show up frequently. Notably absent are words like “directing”, “establishing”, or “dictating”. The observant reader (which I’m certain you are) may start to detect a trend.
Acting as a Guide
The Scrum Master’s job is to ensure that the team is successful. Before we move on, let’s take a moment to let that idea sink in. Scrum is a framework to ensure a successful outcome. It is a means to an end, not the end itself. The team has to succeed in achieving its goals. Attending all of the Scrum meetings doesn’t count for anything if the team is still failing to deliver.
This is where an effective Scrum Master earns their keep. The Scrum Master serves as a guide to ensure that the Scrum exercises aren’t simply additional meetings, but effective opportunities for the team to inspect and adapt. The Scrum Master does this, not by dictating what the team should do, but instead by educating the team on the specific value inherent in each Sprint activity and facilitating said activities to ensure the team stays on track. Easy, right? Exactly! My work here is done.
I jest. If identifying the value in each Scrum activity and staying on track was easy, everyone would be successful. Therefore, to make this process easier, I think the most valuable place to start is by outlining why each Sprint activity is valuable, and what the team should be focused on accomplishing.
Sprint Planning - Defining the WHY, WHAT, and HOW
During Sprint Planning, the team should identify what they plan to do, and how they plan to do it. However, before any plans are developed, the Product Owner should establish upfront WHY each priority work item from the Product Backlog provides value. This is critical for a common understanding of the work involved and will assist the Developers (Scrum refers to all team contributors as Developers for convenience) in addressing the root problem, as opposed to fixating on a specific solution.
Once the WHY is established, the Product Owner and Developers should reach a consensus on WHAT value can realistically (and without sacrificing quality) be delivered during the upcoming Sprint. This must be a consensus. The Product Owner is not allowed to dictate the WHAT, any more than the Developers or the Scrum Master. If the team does not reach a consensus, any estimate of what work can be completed is, to be frank, completely worthless, and the Sprint is already set up for failure. Also, ensure that the team understands this is an estimate, not a commitment. This is a plan made with the information at hand. Should new information become available, the plan will (and should) change accordingly.
Once the WHAT is established, the Developers should build out the HOW, detailing a functional plan of how they will deliver on the Sprint objectives. This is exclusively up to the Developers, and neither the Product Owner nor the Scrum Master should participate in this activity, except to potentially provide additional context (Product Owner) or guidance (Scrum Master).
Outcomes:
From this exercise, the team should produce the following:
- A Sprint Goal: This should clearly identify a target set of work items to be completed during the course of the Sprint (Continue to work on “X” is not acceptable).
- A Sprint Backlog: This should be a detailed plan for delivering the Sprint Goal, typically in the form of work items on a tracking board (anything from post-it notes to a digital board).
Daily Scrum - Is the plan still good?
This one is simple, but oh so often misunderstood. During a Daily Scrum, the Developers (and only the Developers), should determine if they are on track to meet the Sprint Goal. How they do this is up to them, assuming they keep it under 15 minutes. Seriously, that’s it.
Before we move on, I know this is going to give some readers panic attacks. Many people assume that during a Daily Scrum you must answer “The Three Questions” no matter what, and this simply isn’t the case. A team may decide to use this format if they feel it is effective, but they are free to experiment with other formats. Non-Developers may attend Daily Scrums, but they may not participate, and should reserve any questions or comments until the exercise is finished.
Outcomes:
Each Daily Scrum, assuming the participants understand the objective (which the effective Scrum Master will of course ensure), will go one of two ways:
- The Developers decide they are on track to meet their Sprint Goal. Congrats, you’re done!
- The Developers decide they are not on track to meet their Sprint Goal. In this instance, the Developers should identify WHAT is not on track, and WHO needs to participate in fixing it (probably exclusively Developers if the issue is internal, possibly the Scrum Master or Product Owner if the issue is external). They should then establish a time outside of the Daily Scrum to address these issues. Congrats, you’re done!
Anything else is outside the scope of the Daily Scrum. The primary purpose of the exercise is to identify potential problems, not to solve them. Solving problems is a normal sprint activity, and doesn’t require a Sprint exercise.
Sprint Review - WHAT did the team deliver?
This one is fairly straightforward, assuming you don’t miss the last part. At the end of each sprint, the Scrum Team (Product Owner, Scrum Master, and Developers), should invite stakeholders to a formal review of the value produced within the last Sprint. By value, I mean the stuff that is ready. I specifically mean the stuff the stakeholders could have now if they wanted it. Work items that were not finished during the Sprint should not be included during the Sprint Review, lest the team accidentally set unrealistic expectations with the stakeholders that new features are ready when they are in fact… well, not. The stakeholders should then be encouraged to provide feedback on the delivered value so that the team can validate the effectiveness (or lack thereof) of their work.
Assuming they hold a Sprint Review at all, most teams nail this first part. However, this is only the Inspect half of the whole “Inspect and Adapt” thing. During the Sprint Review, any feedback from the stakeholders should be incorporated into the Product Backlog to ensure the new information becomes part of the long-term (Multi-Sprint) plan. Failure to update the Product Backlog robs the exercise of almost all of its value, and it is critical that this step is not glossed over.
Outcomes:
From this exercise, the team should produce the following:
An updated Product Backlog that incorporates stakeholder feedback from the Sprint Review.
Sprint Retrospective - HOW did the team deliver?
Following the Sprint Review, it is important for the Scrum team to take some time to assess the last Sprint to look for ways to improve their internal processes. Any stakeholders (and potentially managers) present should be graciously thanked for their time and excused. Psychological safety is critical for having an effective Retrospective, and teams will rarely be comfortable enough to discuss internal issues in front of non-team members.
This is a formal opportunity for the team to inspect HOW they are working, independent of the value they are working to deliver. There are countless ways to structure a Retrospective, ranging from open discussion to more structured activities. One method I have found particularly effective is to ask the team what surprised them during the last Sprint, good or bad. Basically, what did they fail to plan for? If it was a good surprise, is it something we should incorporate into our standard process? If it was a bad surprise, what could we do in the future to mitigate similar issues? Each team will be different, so it is perfectly reasonable to go through some trial and error in finding a format that clicks for a given group.
Regardless of the format, the team should engage in a frank discussion of their effectiveness during the last Sprint, ensuring all voices on the team are heard (especially the quiet ones). Teams should focus on identifying potential solutions to issues, as opposed to simply pointing out problems. This is not a venting session where teams simply complain for a few hours. Any solutions generated should be included in the Sprint Backlog for the following Sprint (or a future one), and progress should be assessed at the following Retrospective.
Outcomes:
- One or more clearly defined internal optimizations the team will attempt to adopt during an upcoming Sprint.
- One or more clearly defined external issues which should be escalated to the organization (likely, though not necessarily, by the Scrum Master).
It is entirely possible that teams will not have any pressing issues they wish to address at a given Retrospective. Change can be exhausting, and it is perfectly acceptable for a team to stick with their existing process from time to time if it is working well. However, if this becomes the norm, the Scrum Master should probably give the team a nudge to consider improvement.
Conclusion(s)
Hopefully this guide sheds some light on how an effective Scrum Master can guide a team to succeed with Scrum. While there are certainly other opportunities outside the scope of this guide for a Scrum Master to provide value, sound facilitation represents the foundation for any effective Scrum Master. It is the responsibility of the Scrum Master to ensure that all participants fundamentally understand the value of each Scrum exercise, and share a common set of expectations and goals. Remember: the measure of success is whether or not the team is delivering value. Going through the motions of Scrum and failing to deliver is still a failure.
That said, each failure should provide new information to the team about their work, and should be treated as another opportunity to inspect and adapt. As long as the team is committed to improving and sticking to the Scrum Framework, it is perfectly reasonable to expect the team to get better over time.
If you or someone in your organization would like to dive further into effective Scrum facilitation, or if there are other specific areas of Agile where you think you could improve, AgilityHealth® has a variety of resources available to help. AgilityHealth offers a range of solutions ranging from education documents and training videos to expert consulting resources.
Comments