Loading...

Loading...

Scrum vs SAFe – the decision you don’t have to make

  • Posted on January 14, 2021
  • Estimated reading time 4 minutes

This article was originally written by Avanade alum Jatin Patel.

There has been plenty of discussion to compare/contrast Scrum and Scaled Agile Framework (SAFe®️) and this has setup a premise that you must choose one or the other.  But in actuality, Scrum and SAFe®️ are best friends and work very well together.

Both function under Agile values and principles, Scrum focuses at a team level whilst SAFe®️ is scaled to enterprise level. The way you handle work within Scrum is to organise small teams where in SAFe®️ it is used to govern and organise an enterprise, partly made up of these small teams.  They are complementary.

While there are safeguards in place, the necessity of structure in SAFe®️ pressures it towards a more mechanical process that can compromise some of the agile values. In addition to get these safeguards in place you will need more time to set this up.  Using Scrum in combination with SAFe®️ can alleviate some of these pressures and help retain enterprise agility.

In this post I’ll focus on 4 areas of SAFe®️ where Scrum principles can help.

1. Leverage Scrum as your team level framework 
SAFe®️ is not prescriptive about how teams are organized to run; in fact it specifically states "Most use Scrum, a lightweight, and popular framework for managing work”. Therefore, the choice here is with the Agile team itself and whilst SAFe®️ provides guidance on ScrumXP and Kanban, does not limit itself to just using these.   

Let now interleave Scrum into the equation and I suggest underpinning it as the foundation for the Agile team. The value that Scrum brings to agile teams is around Values and Empiricism, both pivotal in their own right. The Scrum values are commitment, courage, focus, openness and respect. These values don’t conflict with SAFe®️ and will complement the success of Scrum teams as they give direction on how people work, behave, make decisions, plan, and execute their tasks.  

The Scrum Guide considers empiricism (three pillars being transparency, inspection and adaptation) to be the foundation of Scrum. This enables teams to make decisions based on fact-based, experience based and evidence-based manner. By removing the emphasis on empiricism, ScrumXP becomes a mechanical process to deliver program Increments. 

2. Break down mechanical processes, syncing delivery through increments
SAFe®️ has received much criticism for its mechanical processes hindering agility. This is prevalent during Program Increment (PI) Planning where you look to plan for up to three months in advance. Let’s break some of these barriers down and look at how to make SAFe®️ more Agile by leveraging Scrum. Scrum prescribes at least one done increment per sprint, the maximum duration of a given sprint is one month and driven by a common Sprint Goal by the Scrum Team. Our view is you can use empiricism better when the increments are shorter periods i.e one month. 

Shorter increments will enable feedback loops more often), which supports agility and your teams to inspect / adapt through sprints in turn helping your organization to increase it delivery value. Yes SAFe®️ has its own inspect and adapt event after the end of each PI but what I like about the Scrum Values and Empiricism is that it supports the Scrum Team to constantly inspect and adapt during the sprint. It doesn’t limit this to end of a Sprint and these are the behaviors you should be looking to adopt – let Agile teams learn through their experiences throughout Sprints. 

SAFe®️ looks to evolve from mechanical processes by leveraging the House of lean principals. Value focuses on getting to the shortest sustainable lead time, thus helping agile teams to hone in on value and embracing an Agile mindset. I must also commend SAFe®️ approach of allowing time for an innovation from Program Increment to Program Increment. We recommend getting your agile teams to consider having an innovation and planning iteration. This helps enforce the refinement but allows people to work on items they wish to as long as it reflects the mission of the company.

3. Creating bottlenecks within the organization?
With its many layers and defined roles, SAFe®️ can feel very top down, however there are merits and necessity to some these roles. A large program of work – say an ERP system will require a ‘System Architect’ to help set the strategy, manage complexity and provide direction through delivery.  This is a role that Avanade has added to our own Scrum teams as is part of our Avanade Delivery Framework (ADF). 

The Product Manager/Product Owner structure in SAFe®️ is another area that could cause bottlenecks.  In Scrum the Product Owner (PO) has absolute authority but in SAFe®️ the Product Owners autocracy is limited with the Product Manager owning the decisions and facing off to Business Owners at the program level.  In this case we’d recommend pushing as much of that responsibility to the PO as possible and as far as is practical being fully accountable for their own domain.

One good aspect of SAFe®️ is that it talks about the concept of a dual operating system, where it looks to leverage the stability around an existing organization. This means it does not break the organizational structure, supports innovation, growth of delivery, operations and supporting existing solutions. We recommend you look to build processes around how your organizations can look to implement agility across its people. This will allow everyone to think alike and develop the right mindset collectively.

4. Keep it simple

My motto has always been keep it simple. I call upon the Agile Manifesto here in particular values 8 and 12; ‘Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely’ and ‘At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly’. 

Taking the above into account, if you’re considering expanding organizational agility, I recommend focusing on the Essential Layer in SAFe®️ and use Scrum at its foundation in the first instance. The SAFe®️ Implementation Roadmap talks about starting with one value stream, but we suggest stating with one product. Use this approach to avoid additional complexities / overheads and interleave the Scrum Values and Empiricisms. By doing this your agile teams are talking and thinking in the same way, thus becoming enablers for your organization. If you’re already using Scrum you should be able to retain much of the current behaviours.

SAFe®️ targets an enterprise organization and whilst a lot of the processes and governance lend themselves well, question whether your organization needs all those additional controls. Think about your organization and look to focus on the core values of agility. When you look to bring in agility across the organization, start off at team level and then look to introduce this to the upwards stream; program and portfolio levels if your organization has these. 

Finally, there are no silver bullets here. Both Scrum and SAFe®️ are frameworks. They are there to guide your organizations; so, understand the value that both bring, look to interleave both together, leave the verses debate behind and thus Scrum becoming your SAFe®️ friend. 
 

Techs and Specs Newsletter

Stay up to date with our latest news.

Share this page
CLOSE
Modal window
Contract