This article is a response to my friend Willem-Jan Ageling’s on the same topic. I believe his post missed some important similarities between the Scrum Master role from the Scrum Guide and the role in the Scaled Agile Framework (SAFe). I’d like to respond to Willem-Jan’s post here.
SAFe Scrum Master vs ‘Scrum’ Scrum Master — Deceptively Alike, But Totally Different
A SAFe Scrum Master does not need to know about Scrum
I’m a Scrum Master, and I’ve worked in Scrum Teams since 2007. I’m also gaining experience in a SAFe context. Currently, I’m a coach in a Lean-Agile Centre of Excellence (LACE) team. Among other things, my role involves coaching Scrum Masters, working alongside Release Train Engineers (RTEs) delivering SAFe training and facilitating program level events. I have also taken and delivered SAFe Advanced Scrum Master (SASM) training. For all of these reasons, I believe my perspective on this topic is relevant.
I should also start by pointing out that I have already discussed this post with Willem-Jan, and we reviewed together before publication. I intend this post to accompany a conversation. By being open and respectful in this dialogue, I hope we can set a good example to others too: we don’t always have to agree on everything, but the conversation is important.
TL;DR — Very Similar Roles
I believe the SAFe Scrum Master is actually very similar to the Scrum Guide Scrum Master. My differences of opinion with WJ’s post can be summed up in the list below, and I will discuss each one in turn:
- A SAFe Scrum Master needs to know about Scrum
- Strictly speaking, we are no longer using Scrum... So what?
- SAFe Scrum Masters help with delivery of value: it’s a principle.
- Transparency is a core value of SAFe.
- In a SAFe context, there are many ways for a Scrum Master to offer service to the organisation
- SAFe is very much a scaling framework for Scrum
- SAFe Implementations need partners, but that doesn’t mean partners are Scrum Masters or that the Scrum Master role must be part-time.
1. A SAFe Scrum Master needs to know about Scrum
While it is theoretically possible for a SAFe Agile Team to not use Scrum at all, I believe this scenario is unlikely in a SAFe implementation.
In SAFe, teams are recommended to use a combination of Scrum and XP. While the label for the combo admittedly looks unusual to me (ScrumXP) I don’t believe the combination of these approaches is in any way heretical: I have seen the two work very well with Scrum Teams myself.
Indeed, back in 2007, when I took some of my first steps in Scrum Teams as a Software Developer, I started with Scrum and XP together. Henrik Kniberg’s ‘Scrum and XP from the Trenches’ was a big influence.
Before that, Ken Schwaber and Mike Beedle, two of the biggest influences on the evolution of Scrum, wrote of how Scrum works with engineering practices. This quote was written in the same year as the Agile Manifesto and both men signed that document:
“If engineering practices are candy bars, then Scrum is a candy bar wrapper. That is to say that Scrum is superimposed and encapsulates whatever engineering practices already exist.”
(from ‘Agile Software Development with Scrum’, by Ken Schwaber and Mike Beedle, written in 2001)
In the most recent Scrum Guide, Ken Schwaber and Jeff Sutherland say that Scrum:
“functions well as a container for other techniques, methodologies, and practices.” (Scrum Guide)
To come back to the point: Scrum is a great container for other practices, but Scrum knowledge is an a priori requirement.
The SAFe framework is built around the rhythms and events of Scrum. A Program Increment (PI) is a series of Sprints — 5 Sprints in my context. The ‘PI Planning’ event happens at the beginning of the PI and is comparable to large-scale Sprint Planning. The ‘Inspect and Adapt’ event happens at the end of the PI and is comparable to a large scale Retrospective.
Even the idea of an Agile Release Train (ART) is comparable to the idea of a cross-functional team in Scrum, only operating at a higher scale. An ART is a team of teams, organised around a Value Stream. To help the ART deliver more value more effectively, dependencies between teams are systematically addressed: Scrum Masters are up to their necks in this activity, but more on this later.
Meanwhile, at the team level, a fundamental starting point for a SAFe Scrum Master is knowledge of the Scrum Events. A key difference is that SAFe refers to Sprints as Iterations: otherwise the events themselves look very familiar. Iteration Planning, Iteration Review, Iteration Retrospective, Daily Stand-Up.
I would only recommend consideration of a SAFe Scrum Master role if you are already very familiar with Scrum and how it is implemented by teams. SAFe will build on that.
2. Strictly speaking, we are no longer using Scrum… so what?
In a strict interpretation of the wording of Scrum Guide, the use of any scaling framework other than Scrum means we are no longer using Scrum. Take this quote from the Scrum Guide as a starting point for this interpretation:
“Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.” (Scrum Guide)
Starting premise: using a literal interpretation of the Scrum Guide, the omission of rules means we’re not doing Scrum any more.
Next step: the Scrum Master role in the Scrum Guide has service to the organisation described as (among other things):
“Helping employees and stakeholders understand and enact Scrum and empirical product development;” (Scrum Guide)
Next step: an organisation uses SAFe. This means we are now doing the above service to the organisation to help employees and stakeholders understand and enact SAFe, instead of Scrum… Oops! Scrum no more?
I do not believe this kind of interpretation is helpful in the trenches. The starting premise is that the document must be interpreted to the letter, and I think that risks a dogmatic interpretation. I value flexibility over dogma.
Interpreting documentation in any context comes with a risk of misunderstanding: I would like instead to refer to principles and values.
3. SAFe Scrum Masters help with delivery of value: it’s a principle.
SAFe is built upon values, just like Scrum, although there is a difference in the expression of those values. In Scrum, the values are my favourite component of the framework and are an expression of something closer to personal values. In SAFe, the core values are more like ‘things we all value’.
SAFe is also founded on principles, just like XP, and this is a key difference from Scrum. However, I believe principles have significant value to guide behaviours and decision-making in a SAFe context.
Martin Fowler is another signatory of the Agile Manifesto. In 2003 he wrote about Kent Beck’s XP ‘White Book’ and described principles as:
“a step between the universality (and vagueness) of values and the concreteness (and dogmatism) of practices.” (Martin Fowler, “Principles of XP”)
(Kent Beck also signed the Agile Manifesto)
SAFe uses 10 principles and they are pretty much all solid foundations for decision-making in an agile context. They apply to everyone in the organisation, including Scrum Masters.
The ART structure described earlier is one way to organise around value. Hypothesis-driven development of Features is another. Both of these elements of SAFe are driven by this principle, are particularly important in my current context, and involve Scrum Masters in several important ways.
One of these is in helping the teams understand the value of their PI Objectives. At PI Planning, a group of ART stakeholders review each team’s PI Objectives and assigns Business Value to them.
These stakeholders are referred to as Business Owners in SAFe and play a very important role in helping teams organised around value. When Business Value scores are assigned, they are typically only relative to the set of objectives in each team. This helps the team understand how to make trade-offs, should difficulties be encountered during the PI.
The SAFe Scrum Master can use these scored objectives as a highly visible artefact for teams during the PI. This is one way to help organise around value, but it is also a way to help achieve artifact transparency.
4. Transparency is a core value of SAFe
According to a literal comparison of documentation, ‘Artifact Transparency’ is not directly mentioned in the SAFe Scrum Master role page, this much is true. However, it would be an omission to fail to mention the fact that ‘Transparency’ is a core value of the framework. You cannot have a successful SAFe implementation without it. If you read through the guide to this value in SAFe, you can see that it refers to visible backlogs. However, more personally relevant to me is the connection between transparency and trust:
“To ensure openness — trust is needed. Building trust takes time. […] Transparency is an enabler of trust, provided through several SAFe practices.” (Source: SAFe Core Values)
Note the reference to openness, one of the 5 Scrum Values. Besides, transparency is supported by principles, as mentioned above. One principle supports transparency in another ART-level event: the System Demo.
The Iteration Review in SAFe is equivalent, but not identical to the Sprint Review in Scrum. However, the System Demo is a part of SAFe, but not part of Scrum. In a System Demo, the teams in an ART give a demo of integrated, ‘done’, working software at the ART level. To achieve this, a ‘definition of done’ must be shared in the ART. Scrum Masters play a role in this practice: helping with the definition and also in sharing it with teams and stakeholders.
At the end of a Program Increment, the teams in an ART give an integrated demo of work completed across the whole PI.
4. There are many ways for a SAFe Scrum Master to serve the organisation
At an Agile Release Train (ART) level, the SAFe Scrum Master serves the organisation by improving the flow of value. At PI Planning, planning together means we tactically identify cross-team dependencies, and building a Program Board helps all ART Stakeholders visualise the dependencies across teams in an ART. This enables a conversation with those outside the teams: how can we build a more cross-functional ART? Scrum Masters are a part of that conversation.
In the Inspect and Adapt (I&A) event, Scrum Masters facilitate Problem-Solving Workshops. This is a very important part of the SAFe Scrum Master role. The problems worked in the I&A workshops on in are not team-level: they are cross-cutting concerns.
One interesting aspect of the I&A: the teams that form around these problems are not the Agile Teams. Problem-solving in an I&A works like a marketplace. The Scrum Masters help with identification of the problems, and facilitate the workshops to identify an Improvement Backlog for the organisation, but teams can form around these problems in a ‘bazaar’ style. You can go to work on a problem that interests you, even if your teammates choose a different one. Any interpretation of the SAFe Scrum Master should consider this as a difference with Scrum: it’s a cool addition!
In a SAFe context, Scrum Masters can also serve the organisation by starting Communities of Practice. This is also a cool way to share knowledge in an organisation and build connections between individuals who might not otherwise know each other or work together. Communities of Practice can be functional (role-based) or cross-functional. All they need in common is a shared domain of interest. I have seen communities of practice for Scrum Masters, Product Owners, Remote Working, SAFe and Coaching. Love them.
There are other ways for a SAFe Scrum Master to provide Service to the organisation: this is not an exhaustive list.
5. SAFe works as a scaling framework for Scrum
I covered this in point number 1 above: SAFe builds on Scrum in several fundamental ways: as a SAFe Scrum Master, it is possible to help teams and stakeholders understand many of the core elements of SAFe with Scrum as the reference.
To reiterate a key point: while in theory, it could be possible to start a SAFe Implementation without Scrum at the core of an organisation, I don’t think it is possible in reality. I would certainly advise any organisation against it. Any SAFe implementation that ignores Scrum would be an oddity at best. I believe it would be destined for a fast failure.
7. SAFe Implementations need partners, but that doesn’t mean partners are Scrum Masters or that the Scrum Master role must be part-time.
I am working on a SAFe implementation where we work alongside a Scaled Agile Partner. The Scaled Agile partner helps launch the SAFe implementation in various ways. We could run through a list here, but I just wanted to address one, related to the Scrum Master role.
The Partner typically coaches the LACE team, RTEs, Scrum Masters and anyone involved in a SAFe implementation. The nature of the partnership will vary depending on context, as is entirely appropriate.
It would be very unusual for Partners to play the role of Scrum Master in Agile Teams and would certainly not be a recommended way for the Partner organisation to add value most appropriately.
In my experience, the Partner organisation are valued consultants, trainers or agile coaches who bring prior experience of the theory and also how it has been applied elsewhere. The Partner organisation works with Leaders, Teams, ARTs and the whole organisation. Use of a partner does not dictate whether a Scrum Master role is played part-time or full-time in an organisation.
Before working on a SAFe Implementation, I believed that the SM to Team Ratio depended on many factors, and it was simply useful to maintain a view of the relationships that work well, and those that might be a little unbalanced. (I wrote about it at Serious Scrum here).
Some Teams need a full-time Scrum Master, and others benefit more from a part-time person in the role. It depends on many factors, like where the team is in its journey with Scrum, how well they are forming, whether they are storming and other factors too.
“All SAFe Agile teams include two key roles, the Scrum Master and Product Owner.” (SAFe Agile Teams)
In SAFe, a Scrum Masters is an essential part of every Agile Team, and the recommendations in SAFe do not override the common sense approach described above, at least not in my own experience.
I hope this alternative view of the differences between a SAFe Scrum Master and a traditional view of the role can complement WJ’s post and offer an alternative point of view.
I humbly offer this alternative view based on my own experience, and am in no way attempting to ‘win the conversation’ or engage in a ‘my framework is better than yours’ debate: rather I am hoping to open a dialogue about how we view agile frameworks and how we can find much in common.
In summary, I have three pieces of advice to offer any reader:
1. Value working implementations over documentation
Just like the agile manifesto principle, do not rush to judge any agile framework by its documentation: I believe working implementations say much more than the knowledge-base of documents that guide it. My experience of a working implementation is positive: that does not mean that yours will be too… I simply offer it humbly as my experience in the trenches.
2. Value values and principles over frameworks
An agile mindset can be distilled and matured in the context of any framework. Our backgrounds inform that personal development, and a deep knowledge of the Scrum framework and its implementation is a wonderful way to develop an understanding of values and principles that can transcend a framework debate. In particular, the Scrum Values help in any agile context.
“we all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work”
(Jim Highsmith, History of Agile Manifesto)
3. Stigmatising frameworks does all of us a disservice
As serious professionals, we need to find what binds us and brings us closer together. We all want to help individuals, teams and organisations to succeed. Right now, I want to help teams and organisations with Scrum and SAFe.
In my opinion, the most powerful message of the agile manifesto is from Jim Highsmith’s history page: values and principles can help us find common ground. The Scrum Master role is in the trenches of that activity.
We diverge from that purpose when we align around tribal boundaries, engage in dogmatic discussions that prompt Manichaean choices, or reinforce differences based on ‘sacred texts’ :) Let’s collaborate instead: that’s how we learn together and from each other.
If you can value working implementations over documentation, value values and principles over frameworks in yourself and others, and avoid a tribal mindset, then you and your team will have a better chance of success with Scrum, SAFe… or whatever agile approach that is helpful in your context.
I very much believe the Scrum Master role is critically important for all of these activities, whether with Scrum alone, or scaling with SAFe.