Source: Scrum Guide, November 2017, Scaled Agile Framework v4.5.

As you see, the differences between SAFe’s version of Scrum and the classic Scrum Guide is relatively small in most aspects. There are a few areas that could have meaningful impact to how your team or organization decides to adopt Agile practices at a large scale.

Difference #1 – Terminology

In most cases, the differences are primarily centered around terminology: the use of “Iteration” in place of “Sprint” is the simplest example. This isn’t a big deal but is important to be aware because once you make the leap into SAFe, your teams will need to make that transition in terminology to ensure consistency with the SAFe framework.

Difference #2 – Timeboxes

One of the biggest differences between SAFe Scrum and classic Scrum is the length of the timeboxes. SAFe generally allows for less time for events due to the additional number of events required in other areas that span multiple teams on an Agile Release Train (essentially a program of multiple Agile teams). SAFe is also more prescriptive and specific about the length of some events such as Iterations, which is recommended to be 2 weeks in duration, as well as Backlog Refinement, suggested at 1 hour per Iteration.

Difference #3 – Dev Team Size

While this may seem like a very minor difference, the minimal size of team recommended by SAFe is larger, 5 as compared to 3 in classic Scrum. As you attempt to scale Scrum to multiple teams, this difference could significantly impact how you staff the teams, especially if you currently have mostly small Scrum teams. The net effect of this difference is that to adopt SAFe practices, the Scrum teams that only have 3 members in the Development team will need to accept new members, which in most cases will put the team back into the “Forming” stage of the team development cycle. This will more often than not result in reduction of team productivity, which may not be avoidable anyhow, but is important to recognize as a risk.

Closing Thoughts

On the surface, it appears that the differences between Classic Scrum and SAFe Scrum is fairly superficial and insignificant.  However, if you take a closer look at some of the differences, one might argue that SAFe’s instantiation of “Scrum” is inconsistent with the Scrum Guide, and should no longer be considered “Scrum”. Being more of a pragmatist than a purist, I don’t believe that this distinction is all that important. What matters more to me is that SAFe provides a more prescriptive approach to the “how” of Scrum as compared to the Scrum Guide, which primarily focuses on the “what” and relies on the practitioners to figure out the “how”.

The level of rigor and prescription that is needed or desired for an Agile framework is a highly-debated subject, one that would exceed the scope of this article. I think that the important takeaway from this comparison is the acknowledgement that Scrum experts/practitioners will need to adapt themselves and enhance their domain understanding of SAFe if they wish to apply their skillsets; this is because the differences in terminology and practices could have a direct impact on the level of success from a transformation initiative for the organization that strives to adopt the SAFe framework.

So how would an experienced Scrum practitioner make the leap from “traditional Scrum” to a scaled environment? My recommendation is for you to take formal training and supplement the team with an experienced Agile Coach who has direct experience leading such transitions. Some courses I would suggest looking into are SAFe for Teams, SAFe Scrum Master, and SAFe Advanced Scrum Master.

For Scrum teams that are accustomed to working independently, it is imperative to start looking into how to collaborate with other Scrum/Agile teams to work through technical dependencies as well as communication mechanism.