SAFe® 6.0 Deep Dive – SAFe Scrum

According to the latest release of SAFe®, “SAFe Scrum is an Agile method used by teams within an ART (Agile Release Train) to deliver customer value in a short time box. SAFe Scrum teams use iterations, Kanban systems, and Scrum events to plan, execute, demonstrate, and retrospect their work.”

SAFe 6.0 provides a few minor modifications to the construct of what was formerly “ScrumXP”, a merger of the Scrum framework and XP (Extreme Programming). I have highlighted a few key differences below to call out specific changes. Let’s explore these more closely and see if they truly matter to you and your teams.

Changes to SAFe Scrum

What are the key differences?

Terminology aside, the conceptual change from “ScrumXP” to “SAFe Scrum” is not materially significant. But, there are a few differences to be aware of.

Removing “XP”

SAFe indicates the XP practices (such as pair work, continuous integration, etc.) are now integrated into other areas of the framework, which is why they removed the “XP” moniker. I believe that this simplification makes sense and will probably reduce confusion, but not much value beyond that.

How big should a team be?

The next change is related to the recommended team size. SAFe 6.0 is now aligned with the most current version of the Scrum Guide (2020) in terms of ideal team size (no more than 10). While “5 to 11” from SAFe 5.X does not appear to be much different, this change increases the flexibility somewhat by eliminating the lower limit of five, implying you could have a team with fewer than five people if you choose.

Daily Stand-up is not daily!?

Next, we see a change regarding the frequency of the daily team meeting, formerly known as the Daily Stand-up. Instead of mandating a daily occurrence, 6.0 provides a more general recommendation of “about daily”, which means the teams may choose to NOT meet daily. While this may provide more freedom for teams to decide how often they wish to revisit their plan towards sprint/iteration goals, I am concerned that some teams will use this wording to justify a weekly meeting, which would follow a more traditional status meeting mentality. I believe teams should remain vigilant and have the discipline to meet daily until they have reached a state of maturity and understanding of how to collaborate effectively within the Agile/SAFe paradigm.

Master or Coach?

The next change is related to the title of the Scrum Master role. By adding the “Team Coach” moniker, they place more emphasis on the Scrum Master’s focus area, which is to provide coaching and guidance to teams rather than serving as an administrator of tools. I believe this is a good enhancement that highlights the key duties of the Scrum Master and helps to clarify the value of this role.

Clarifications of differences between SAFe and Scrum

The remaining items highlighted in the table are not specifically tied to the SAFe 6.0 update, but a clarification of the difference between SAFe and “classic” Scrum (e.g. the Scrum Guide). As you see, the time boxes for some events are different between SAFe and the Scrum Guide, which may not be significant, but they’re noteworthy. If you have a large train with several teams, these may make a difference in terms of the overall investment made in the various events.

Which changes should you care about?

Depending on where your organization is in your SAFe journey, some of these modifications may not be meaningful. If you have existing trains that have been operating for several months or years, making these adjustments may require more effort and time than you expect.

If you are just starting your journey and preparing to launch your first train, adopting SAFe 6.0 terminology and practices may be simpler for you because you will probably avoid the barriers of preconceived notions or mindsets that have been established already.

Closing thoughts

The important thing to keep in mind is that SAFe is a framework, and it should be customized to fit your context. The risk here is not knowing what to customize and unknowingly taking away practices or constructs that reduce your overall agility and/or quality.

To avoid this, it is usually a good idea to engage experienced SAFe practitioners and consultants to assist you with this process. SAFe can be a highly effective approach to building great products and solutions, but there will always be a learning curve with any framework, and seeking help can accelerate your adoption significantly.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Eugene Lai, Contributor