After studying the Scrum Guide on multiple occasions over the past few weeks in preparation for a PSM1 Scrum Master certification workshop, I realized that there are several distinct differences between the “classic” Scrum and SAFe’s application of Scrum-like practices. I decided to do a deeper dive into how Scaled Agile Framework (SAFe) utilizes Scrum and found some interesting points that surprised me. I would like to share these observations with you so that you can make an educated decision before selecting SAFe as your Agile scaling methodology.
Most teams that I have worked with adopt Scrum based on the Scrum Guide since it has been around for many years, and is considered by most Agilists to be the standard. However, as SAFe continues to grow in popularity and adoption across various organizations, the differentiation between how SAFe leverages Scrum and basic Scrum can become challenging, especially for those who already have extensive experience practicing “classic” Scrum.
To help those folks who may not have the time or budget to attend SAFe courses, but are interested in gaining a deeper understanding of Scrum within the SAFe domain, I have compiled a summary of my assessment below. I will share a few points that I found to be interesting based on my experience applying both Scrum and SAFe for teams. To obtain a full understanding of how Scrum works within the context of SAFe framework, I recommend taking the “SAFe for Teams” training course.
|Characteristic / Terminology||“Classic” Scrum (Scrum Guide)||SAFe 4.5 Instantiation of Scrum|
|Name of Team||Scrum Team||Agile Team|
|Team Members||Development Team, Scrum Master, Product Owner||Dev Team, Scrum Master, Product Owner|
|Dev Team Size||3 to 9 people||5 to 9 people|
|Team Method||Scrum||Any combination of Scrum/XP/Kanban|
|Daily Collaboration||Daily Scrum||Daily Standup|
|Planning Event||Sprint Planning||Iteration Planning|
|Review Event||Sprint Review||Iteration Review|
|Retrospective Event||Sprint Retrospective||Iteration Retrospective|
|Backlog Refinement Event||Backlog Refinement||Backlog Refinement|
|Review/Demo Event||Sprint Demo (single team)||Single-team demo (at Iteration Review), supplemented by System Demo (all teams)|
|Timebox Sprint/Iteration||<= 1 month||1 to 4 weeks acceptable; 2 weeks recommended|
|Timebox for Sprint/Iteration Planning (for 2 wk Sprint)||<= 4 hours||<=4 hours; 2 to 4 hours recommended|
|Timebox for Sprint/Iteration Review (for 2 wk Sprint)||<= 2 hours||1 to 2 hours|
|Timebox for Sprint/Iteration Retrospective (for 2 wk Sprint)||<= 1.5 hours||<=1 hour|
|Timebox for Daily Scrum||<= 15 minutes||<= 15 minutes|
|Time allocation for
|<=10% of team capacity||~ 1 hour|
|Sprint/Iteration Goals||Sprint Goal||Iteration Goal|
|Backlog of Work (Team Level)||Product Backlog||Team Backlog|
|Content of Backlog||Features, functions, requirements, enhancements, fixes||User and enabler Stories; improvements, refactors, maintenance, defects, technical debt, spikes|
|# of Backlogs in Multi-team Environment||1 backlog for all teams||1 Team Backlog for each team|
|Definition of Done (DoD)||No specific guidance. Team decides what is acceptable.||Example scalable DoD defined as reference.|
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.
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.