Making the Most Of Scrum: Avoid These Misconceptions
Published: 2022-12-13Recently I performed a 'Deep Dive' into Scrum: its machinery, its purpose and its goals. Not long after, I was fortunate enough to have some conversations with an Agile Coach in Vietnam, Chris Kruppa of semdi, and we both agreed that there were a few things that are often mis-understood about Scrum or running agile teams. This post describes two of them. Check out the other two misconceptions on the semdi Blog!
The Daily Scrum is for Reporting
It is key to understand what role the Daily Scrum (sometimes called the Daily Standup) plays within the Sprint. To do this we must remember what the purpose of a Sprint is and to in turn treat it correctly; Chris explains this in his post and reveals how you might be setting poor sprint goals.
The book "A Scrum Book" has one of the better descriptions of what the Daily Scrum is for and how it should be implemented, and there is a valuable insight in its first definition:
"Have a short event every day to replan the Sprint, to optimise the chances first of meeting the Sprint Goal and second of completing all Sprint Backlog items"
Wait, what was that? The completion of all the backlog items is only the second priority? Yes, and this is why the Daily Standup is not for reporting - it is for replanning. The Sprint is executed in order to accomplish a product goal, which is typically a problem that the users need to be solved. This goal is expressed as a list of tasks to be accomplished, but the selection of these tasks by the team in the Sprint Planning is simply step 1 in iterating towards achieving that goal.
The soul of the sprint is to be constantly and purposefully replanning the sprint activities to achieve the sprint goal, and the heartbeat of the Sprint is the Daily Scrum.
I read "The Checklist Manifesto" by Atul Gawande recently. It has a deceptively misleading title. The central narrative may be about creating effective checklists but the book dives into how teams can deal effectively with complex problems. As any software developer knows, every sprint represents a complex problem - similar I would say to the surgical teams described in the book. Atul describes how his drive to improve surgical outcomes rested on clear communication of expectations, helping the team and replanning if necessary.
This is why running the Daily Scrum as a reporting session is bad - it breaks the feedback cycle. If the meeting only consists of reporting, then there is no useful feedback being given to assist the team in re-planning to meet the goal. What if one of the tasks recently completed means that a subsequent task no longer needs doing? Or can be greatly simplified? What if one task has revealed a large technical issue which is difficult to solve? How can that task be achieved quickly? Should the sprint now be re-planned to meet the goal?
Recently the "three questions" of the Daily Scrum were removed from the scrum manifesto, and I think this is a good thing. The 3 questions are perhaps a good starting point for new teams which are learning how the Scrum machine works, but as the team improves then they should evolve these questions (for example use questions focussing on the group and the goal rather than the tasks) and ultimately develop into a team which knows how the Daily Scrum needs to foster transparency, collaboration and adaptation.
Which brings us to the Scrum Master.
The Scrum Master is a Meeting Organiser
I listened to an introductory Scrum course recently which stated that the Scrum Master's role is to facilitate the Scrum events. This pricked up my ears because it is very easy to mis-understand what is meant by 'facilitate', and I did not think this was made very clear by the presenter. This is not to say that the Scrum Master should not be leading meetings some of the time - the Scrum events do need to be executed according to the goals and spirit of Scrum, and so the Scrum Master does indeed need to direct them when necessary. But they are not simply an organiser, and this is why it is important to understand the word 'facilitate'.
Moments later, the presenter showed a bullet point saying that the Scrum Master is responsible for maintaining the product backlog, which also furrowed my brow. If your Scrum master is only managing the backlogs and walking through meeting agendas then they are well and truly being wasted.
I wrote a piece last year about Re-Learning Scrum, in which I described the role of the Scrum Master, and it can be summed up very simply: "Make the team go faster". "But" I hear you say, "isn't that what Scrum is meant to do anyway?". Yes, you are right. However as my other post concluded, Scrum is not a management tool; it is a framework, essentially a new way of thinking. Transitioning from an old paradigm to a new one is difficult, and Scrum's designers understood this.
Jeff Sutherland writes in his book on Scrum about what they discovered in the "first" Scrum team:
"we needed someone whose job it was to make sure that the process was effective. Not a manager - more of a servant-leader, something between a team captain and a coach [...] It was the Scrum Master's job to guide the team toward continuous improvement."
The Scrum Master is intended to be the embodiment of Scrum; he or she is the captain, guide and coach, a driving force for improvement. They are not a meeting organiser, and their responsibilities do not start and end in meetings.
How is it best to describe this? Every one of us lives inside bubble, a bubble of what we know and what we experience. It is a bit like a minnow trapped inside a drop of water. This is not our fault - we have been given focussed jobs to do and trained on doing them and we do them well. But this focus means it is difficult to put extra effort into discovering what might be affecting us outside the bubble.
Scrum intends to change the bubble. A good Scrum Master is able to observe the team and communicate what opportunities there are and how to grasp them. They help the team to discover and fix what is in their way. Sometimes they will do activities themselves - perhaps they make connections that are important to the team, or suggest changing the team structure to be more cross-functional. But ultimately the team also has to learn how this is valuable.
I talked about this with Chris at semdi and he told me he was fortunate enough to witness the same team with two different Scrum Masters. In the first instance, the Sprint Review and Planning meetings were dry and devoid of communication. Through use of a simple metric, it was obvious that only a few days after starting a sprint the team was lacking confidence in completing it. Then the Scrum Master changed. "It was like seeing a different team" he told me; the meetings were lively with the developers leading the discussion and debating amongst themselves, even though the Scrum master was silent in the meeting. Confidence in the team went up. This is the secret sauce that lives in the Scrum Master.
Conclusion
From analysing these misconceptions alongside those from Chris, we can see that Scrum is one big jigsaw: if you do not set the right Sprint goals, then you will be setting your team up for potential failure because they will not have the ability to optimally self-organise in order to achieve the goal. If the Daily Scrum is about reporting task completion then the team will be limited to simply re-shuffling the tasks they are given, not empowered to regularly decide how to best achieve the goal. If the Sprint Review is only a demo to the Product Owner, then the team misses out on valuable feedback to see if the goal has actually been delivered, and also influences the next goal. The Scrum Master is there to help the team in understanding this and ensuring it does not happen.
About the Collaborator
Chris is a German working in Vietnam since 2008. He became passionate on Agile, when he started to implement Agile into his Marketing team about 2010. He immediately saw the impact of cross-functional and transparent teams and became a CSM in 2011. He founded semdi solutions in 2012 with the goal to coach teams on how to be more adaptive and ready for the 21st century. Since then, he has worked with nearly 20 organizations in Southeast Asia and supported them in increasingly becoming more Agile.