There are a number of agile methods in existence today. Originally dominated by Scrum and XP, the suite of processes has expanded to include a host of enterprise-level frameworks such as SAFe, DSDM, Disciplined Agile Delivery, and many others including Lean-Kanban variants. Each represents a particular way of working that conforms to the principles laid out in the Agile Manifesto, and most prescribe roles and responsibilities to go with them. These roles and responsibilities differ between these methods, because the very practices themselves differ, even though all comply with over-arching agile principles. But have you noticed that there always seems to be one particular role that is assumed to exist across the whole gamut of them, and a corresponding question for which every agile team is expected to have an answer:
Who is your Scrum Master?
If you think about it, that's really odd. Why should XP or DSDM teams - to say nothing of Lean Kanban ones - be assumed to have a "Scrum Master"? It's as though this particular Scrum role is woven into the very fabric of agile practice, and a team lacking a "Scrum Master" can't really be agile at all. What's going on?
Well, I'd argue that there are three forces at work here:
- The Fiat Currency of Scrum Certification. Both scrum.org and the Scrum Alliance operate certification programs for Scrum Masters, as well as relevant training courses. Many thousands of people have gained a qualification through one or both of these systems. It's fair to say that they have a high recognition factor in the industry. The presence of such certifications has bolstered the association between agile transitioning and the very name "Scrum Master". If you can be said to have a "Scrum Master" on your team, it implies that robust agile sponsorship is in place. The cachet has propagated beyond Scrum and gained currency in many other agile ways of working.
- Scrum as a "Cargo Cult". If the appearance of Scrum can be approximated by dysfunctional organizations, they often hope that they can leverage the benefits that Scrum has been observed to bring elsewhere. According to the State of Agile Development Survey, Scrum is by far and away the most widespread agile method that is claimed to be in use. Even though the proportion of alleged implementations that genuinely apply the full rigour of the framework is tiny, the words that belong to it have swept the industry. Troubled organizations relabel their people and practices in Scrum terms, and from this magic they expect results to follow. Yet their "agile method" is often little more than a collection of totem words, where unfamiliar ideas mix with old superstitions, and masquerade as a new science. Within the dark recesses of this jungle lie the Scrum Masters that aren't.
- A Renaissance in Servant Leadership. Behind the name is a role, and a pattern of duties and responsibilities. The name "Scrum Master" represents a pattern known as Servant Leadership. A Servant Leader manages a team not by telling them what to do, but by removing impediments that get in their way and by coaching them in agile best practices. It can be thought of as a type of stewardship. This team-focused approach is not unique to Scrum...for example, the Coach of an XP team also demonstrates this principle. This is a case of certain agile methods having Scrum Masters by analogy. In their rubric they may use different terms for a Scrum Master, and they might refactor some of the responsibilities across several roles. Yet the term Scrum Master is used in practice because it most clearly represents the principle of agile stewardship in the flesh.
So what does a Servant Leader actually do?
Regardless of whether you call it a Scrum Master or not, this role brings with it the responsibilities of stewardship mentioned above. I've heard the role referred to as a Team Sherpa - appropriate, one would suppose, if the team uses BaseCamp. Anyhow, here is a checklist of key practices which the person fulfilling the role will need to demonstrate.
- Shield the team from diversions and distractions
- Facilitate planning sessions
- Facilitate reviews and retrospectives
- Coach the team in agile best practices
- Help the team to collaborate better
- Advocate the team's position
- Find ways to remove team impediments
- Make sure daily stand-ups happen, and are conducted properly
- Encourage transparency and associated metrics
- Understand and explain the team’s progress to interested stakeholders
- Arbitrate between team members when necessary
Antipatterns of stewardship: What a Servant Leader doesn’t do
- Direct the team by telling them what to do. Instead, he or she should assist the team to self-organize and do what it takes to expedite their progress
- Manage the daily stand-up. A Scrum Master should simply ensure that the stand-up happens and is conducted properly.
- Estimate the team’s work. If an agile team are using estimates in their planning, they must be responsible for them. The Scrum Master will arbitrate if needed.
- Go off his or her own sweet way. A good Scrum Master will always maintain an awareness of where the team is in relation to its goals.
What to do nextUse the above lists to decide whether or not your team actually has a Scrum Master in the first place...and if so, ask if they are a good fit. The answer may surprise you. The best person isn't always the one who may have been assigned to the job. Nor is a project manager necessarily well suited for "servant leadership". A Scrum Master might be a lowly developer who takes care of things other team members don't like doing...the best are often the "gofers" that hold the team together. On the other hand it might be a business analyst who is outward-facing enough to advocate a team position and remove impediments. BA's aren't called "boundary spanners" for nothing!
If you don't have a clear fit for a Scrum Master, the chances are you still need one anyway. After all, if a team is to both deliver and improve, there will surely be a need for someone who can guide it, protect it, remove its impediments, and be its "Servant Leader".