Do the Scaling frameworks stay true to Scrum?
Scaling Scrum: assessment and rating of SAFe (Scaled Agile Framework)
Scaling Scrum, part 10
This is part 10 of the series:
Disclaimer
Before you think about scaling Scrum, consider if this will truly resolve your issues.
Don’t scale until you have fixed your issues with Scrum adoption. Many reasons to scale Scrum can be removed by ‘doing Scrum’ properly.
Scoring explained
With this article I intend to assess SAFe by comparing it to Scrum according to the Scrum Guide. I will address where SAFe impacts Scrum for every attention area. Why do I assess it like this? Well:
Every role, event and artifact has a purpose. “Scrum exists only in its entirety” — Scrum Guide 2017.
Whenever the purpose of Scrum is impacted by the scaling framework this will impact the score. This means that if a framework performs incisions into the Scrum framework, the result would reduce the efficiency of Scrum.
I will give scores from 1 to 5:
- 1: doesn’t meet the purpose as Scrum described it
- 2: barely meets Scrum’s purpose
- 3: some elements seriously impact Scrum’s purpose
- 4: has a small negative impact on Scrum’s purpose
- 5: fully meeting Scrum’s purpose
Scrum
For your reference: here’s the link to the Scrum Guide. My understanding of the Scrum Guide forms the basis of my assessment.
Introduction to SAFe
Here is a link to an introducing of SAFe:
Here ends the introduction. On to the assessment!
Assessment
Maximizing Product Value
Scrum is:
“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — Scrum Guide 2017
This is the whole reason to use Scrum in the first place. For me it’s the number one thing that needs to remain in place. Therefore, the score for maximizing product value weighs three times that of the score for events, artifact or roles.
SAFe has many additional layers above the team level. All these layers come with additional events, roles and artifacts. The responsibility for the product sits somewhere in a top layer and not with the Product Owner. Also SAFe has Release Trains typically taking five Sprints. These Release Trains can hinder timely inspection and adaptation in case items don’t bring the expected value. Then there’s the notion that all teams should work in a certain cadence. Also this doesn’t help teams to backtrack in case of wrong decisions.
Score: 2
Empiricism
The SAFe framework has many roles, events and artifacts throughout the framework. Decision power is scattered allover, unlike how it works in Scrum. Teams are expected to work in a certain cadence in — typically — 10 week cycles. This all has a huge impact on your option to inspect and adapt. Below are some examples, but I could go on and on.
SAFe incentivises emphasis on reporting metrics rather than empiricism. You planned something during the Program Increment planning, are you ‘on track’? Within Scrum it is seen as a given that a team will find out new things that will have an impact on the Sprint Backlog and even the Sprint Goal. Within SAFe — promoting the cadence — you would severely impede other teams and slow those down. Therefore you think twice to deviate from the what was agreed upfront. Very un-Scrum.
The Release Trains also give you the incentive to deliver according to what was agreed during the Program Increment planning instead of inspecting and adapting every Sprint. Scrum basically says that you can’t plan beyond the Sprint. SAFe disregards this.
Score: 1
Roles, Events and Artifacts
Below are individual assessments on roles, events and artifacts that result in one average score.
Scrum Roles
The Product Owner within SAFe is responsible for prioritizing the Team Backlog, not the Product Backlog. This is trickled down from higher levels (Product Manager, maybe even Solution Manager or Epic Owner). This is not in sync with how Scrum views the Product Owner. In Scrum everyone should respect the decisions of the Product Owner. In SAFe the items are presented to the Product Owner.
SAFe proposes all kinds of best practices to be used by the Development Teams. SAFe promotes alignment in ways of working between the teams and emphasizes that all teams should work in more or less the same pace (they should develop in a cadence). So not only the Sprints are aligned (start, end, length), but also the working pace of the teams is aligned. The fact that teams need to move in a certain pace limits their self-organisation as described in the Scrum Guide.
The Scrum Master in SAFe has all the responsibilities that are also mentioned in Scrum. However a SAFe Scrum Master does more. She facilitates all the events (including the daily event), coordinates with other teams, helps facilitating additional SAFe events. Some of these tasks are not in line with the responsibilities of a Scrum Master as discussed by the Scrum Guide. A Scrum Master isn’t the coordinator of the team. The Scrum Master also doesn’t have to be at events like the Daily Scrum.
On top of the team level — at Program, Portfolio, Business level — SAFe knows many additional roles. One could argue that these are outside the “Scrum” space, but roles like Product Manager, Release Train Engineer, System Architect/Engineer, Solution Manager, Solution Architect/Engineer, Solution Train Engineer, Epic Owner, Epic Architect have impact on how the teams function.
Score: 1
Scrum Events and Refinement
SAFe dictates a length of the Sprints for all teams, typically 2 weeks. It also determines that the Sprints should be synchronized, as it is with the other frameworks. SAFe also dictates that Release Trains are a number of Sprint — typically 5 — and that the final Sprint is a hardening/planning Sprint. Hence SAFe has many items that differ from a standard Scrum Sprint.
On top of the Iteration Planning which is similar to Scrum there are also planning sessions on higher levels that have direct impact on how the teams can determine the Iteration Goals and backlog items: Program Increment Planning (taking 2 days), Solution Backlog, Portfolio Backlog.
SAFe has a Daily Standup that is quite similar to a Daily Scrum. Main difference is that the Scrum Master has an active role. In Scrum there basically is no role for the Scrum Master at the Daily Scrum. In SAFe she makes sure that the ‘meet after’ discussion is conducted to address issues raised at the Daily Standup.
Within SAFe the Iteration Review closely resembles Scrum’s Sprint Review. However SAFe is far more descriptive on what to do during this review.
SAFe Team Retrospectives are done very much like Scrum’s Retrospectives however more prescriptive.
Refinement within SAFe isn’t described in detail. It is assumed to be standard Scrum.
Apart from the events on team level there are multiple events that require the teams to be attending: Agile Release Train Planning, maybe even the whole Training and Innovation iteration of 2 weeks.
Score: 1
Scrum Artifacts and Definition of Done (DoD)
Every team has a Team Backlog, not a Product Backlog. This is trickled down from higher levels (Program Backlog, Solution Backlog, Portfolio Backlog).
SAFe works with an Iteration Backlog, similar to a Sprint Backlog.
The Increment in SAFe is a step towards the Program Increment and therefore far less prominent than within standard Scrum.
SAFe has many additional artifacts like increments on different levels and backlogs on different levels.
SAFe works with a DoD much according to Scrum but it stands in the shadow of the concept Built-In Quality.
Score: 2
Average score roles, events, artifacts: 1.3
Verdict: 1.6 out of 5
Here are the results from my assessment of SAFe to scale Scrum:
Product Value is the purpose of Scrum and this is why I weigh it 3 times the roles, events and artifacts. Empiricism is the cornerstone of Scrum and therefore I decided it has twice the weight of the roles, events and artifacts.
- SAFe puts the purpose of Scrum — maximizing product value — under heavy pressure due to it’s top-down approach, additional layers and as a result additional roles, events and artifacts.
- SAFe also severely limits empiricism. Several roles and events are still there, but largely lose the intention of transparency, inspection and adaptation.
- The many roles, events and artifacts do seriously impact Scrum’s lightweight structure.
SAFe scores lowest of all the scaling frameworks. Where other scaling solutions can result in a flatter and drastically different organisation SAFe takes away these incentives. With that SAFe allows all to remain in a status quo which is exactly what Scrum wishes to break.
Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!
My twitter profile is https://twitter.com/WJAgeling
