The Pros and Cons of the Scaled Agile Framework

When you walk to the edge of all the light you have and take that first step into the darkness of the unknown, you must believe that one of two things will happen. There will be something solid for you to stand upon or you will be taught to fly. ― Patrick Overton

The Hurricane effect:  

In 2005, the US Government declared a state of emergency in Florida and a few neighbouring coastal areas. They were preparing for what was going to be one of the most devastating natural forces in modern history – Hurricane Katrina. The situation was chaotic with millions of people being evacuated from their homes, shelters running out of supplies and weather forecasts reaching new levels of unknowns.   

However, there were two people who were attempting to do the unthinkable. A reporter from a leading broadcasting company and a scientist from NWS were planning to understand the phenomenon better. They were preparing themselves to capture footage and data, by entering the inside of the ‘Eye’ of the hurricane; something unthinkable given the hazards of being at the epicenter of such a huge storm. The benefits though were remarkably crucial, with the data captured to be used for important scientific analysis and research, to help prepare better for such hurricanes. However, the big question was, would they survive?   

Much like the above scenario, SAFe® (Scaled Agile framework) is a modern-day IT storm that has hit the industry. When SAFe was introduced in 2011 not everyone was prepared for its landfall moment, but as more niche versions came out and the flexibility to apply it at various levels was rolled out with improvement of business agility at its core (the eye), many organizations have started to realise the benefits.  To know more about SAFe agile certification, click here.  

However, the big question in this scenario is, how many of us have managed to get a peek inside the eye of this storm?  Have we managed to utilise SAFe to realise potential business agility?  In this article, we will be exploring exactly this along with the pros and cons of applying SAFe framework at your organization.  

What is SAFe? – a brief introduction  

SAFe is a way of taking any iterative Agile way of working (normally restricted to a few teams) and scaling it up at various levels of the organization, whilst applying a mindset of Lean manufacturing. SAFe feeds on the factor that there is an enormous need for adaptability in the industry, especially for large enterprises which are bogged down by legacy processes and outdated technological hierarchies but somehow need to stay relevant in the market, unable to respond to a rapidly changing customer need. If applied correctly, SAFe will empower businesses to compete in today’s marketplace and help them thrive in what is already a chaotic era of digital transformation. The SAFe certification course further enhances the understanding and application of this framework.

It is to be noted that since its launch, SAFe has had many versions rolled out, with the latest being SAFe 5.0, which is a significant update from the framework perspective itself. This version handles key guidance over several core competencies that will ultimately transform an organization into a Lean Enterprise and achieve Business Agility. 

Being an Agile enthusiast myself, I quite often get asked about when and why should we start using SAFe? Will it really work? etc. Hence the main purpose of this article is to is to bring out some general Pros and Cons (For and Against thoughts) that are out there in the public. This article will focus only on SAFe and will not be used to compare it with any other scaling framework. 

Pros of SAFe: 

SAFe is very relevant and designed to thrive in situations where there are significant cross functional dependencies between agile teams and support / functional teams (infrastructure teams, architect community etc). Although there are numerous benefits of properly implementing SAFe, below are some of the key Pros which we will be highlighting in this article. 

• Scalability at various levels – Beginning from Essential SAFe right up to Full SAFe, the framework caters to all organizational levels trying to scale agile. As part of this, it broadens the core idea of the agility mindset beyond just projects/development teams and extends it right up to executives/CXOs, who must prepare for enterprise level uncertainties. So, it provides valuable enterprise level scaling insights that executives will find useful while having to tackle any of these uncertainties/risks. 
• PI planning & Dependency management – According to me, PI planning (hands down) is THE most significant aspect of executing this framework. This is where all the magic happens. It is sometimes referred to as the heart of the framework as it offers a clear vision of what the program increment needs to be, what the cross-team dependencies are and brings together the cultural sustainability much needed within the release trains. It is so important, that if carried out incorrectly it could lead to several ambiguities, development challenges and mostly a disastrous product increment. However, when it works well, the iterative cycle serves to flesh out the crucial elements of the plan, and the processes ensure buy in from the stakeholders. A normal PI planning is a 2-day activity, which is a face to face cultural get together of the various ART teams. However, a new 3-day distributed PI planning has been introduced to help with geographically distributed teams (across various time zones), very apt for the current pandemic situation.  

“There is no magic in SAFe® except maybe for PI Planning”. – The authors of the SAFe framework. 

In big organizations with multiple distributed teams across multiple vendors, work streams etc. teams have to run independently whilst still having to deliver an incremental program. SAFe via the PI planning exercise mentioned above, helps with sorting out these issues by recognising cross team dependencies upfront and constantly negotiating & visualising them. This doesn’t just stop with the PI planning, but the framework also proposes a cadenced way of continuing this via the scrum of scrums. The Program Board is an ideal way to showcase the cross-team dependencies.

• Improved Time to Value – The great philosopher Aristotle once said “The whole is greater than the sum of its parts.”. Imagine a republic day parade where there are several regiments of the army, navy, and air force, along with their bands, all marching in synchronization. Regardless of whether you are a foot soldier, a wing commander or the president of India or somewhere in between, everyone is following the same process, protocols, creating a unified collaborative event. Much like this, in SAFe almost all parts of the organizations from scrum teams, ARTs, portfolio teams and C level executives, collaborate at an enterprise level by marching to the same drum beat, towards a unified set of goals. What this does is, it helps with a unified planning & execution, repeatedly, whilst incorporating timely feedback at all levels and thereby delivering value faster. 

A customer story from Scaledagile.com website has a quote from a leading financial services company’s Agile coach – “Our time-to-value has gone down using the SAFe process. If reaching production would normally take 1 1/2 years, now it could be eight months with the new processes and approach.” A wonderful achievement indeed. Isn’t it? 

• End User driven ideology – Having an empathetic mindset towards product design, build execution & delivery is a critical factor for the success of any product. SAFe proposes a primarily research driven, customer centric enterprise, focusing on producing empathy maps prior to the design phase to exactly understand how the end user will be impacted for any decision the enterprise makes. This also helps the organization to better understand market rhythms and stay ahead of the hype cycle, tapping into important unexplored areas giving the much-needed edge.  
• Alignment to business goals – What SAFe does (and does beautifully) is, it breaks some of the silos between business and technology. It actively encourages business stakeholders to interact / brainstorm with the relevant IT product delivery teams. The stakeholders also help to quantitatively prioritise initiatives/work items by assigning each item a business value, thereby aligning the business and technology in terms of the enterprise level goals, values and ultimate vision. The interaction mostly happens through various events that are embedded in the framework itself like PI planning, system demos, scrum of scrums etc. Remember the last thing that we do not want to happen in an enterprise-wide transformation is a total misalignment between business strategy and IT delivery.   
• Enterprise Business Agility – At the end of the day, whichever framework an organization uses to scale agile, it is of no use unless it helps the organization to thrive in this chaotic digital era wherein the key lies in the time taken to respond to market changes and dealing with ambiguous yet emerging opportunities. As mentioned in the above point, SAFe helps in aligning the business and IT strategy, making sure that there is a growing hierarchical structure running in parallel with an entrepreneurial network. This kind of a customer centric framework helps in offering both efficiency and stability served with a hint of innovation. 

Cons of SAFe:  

• Too many jargons/terminologies to remember – SAFe does have a heavy usage of terminology. To name a few, they sound like this - release trains, Program Increments, runways, guardrails, enablers, spikes etc. Phew !!! let’s just take a breath eh?! Also it has its own way around things, when it comes to Agile terminologies. SAFe has managed to modify some of the common agile terms & processes in order to fit into the "framework" that they prescribe. For e.g. a sprint is referred to as iteration, story points come with prescriptions and spikes get estimated. Why would someone need to estimate and size Spikes?  
• Can seem more like a Push rather than a Pull (top-down approach) – This is another seemingly un-intentional drawback of the SAFe framework, mainly because of multiple layers of administration and co-ordination. There are specific roles at each layer which tend to take away some of the obvious freedom from developers (unlike Scrum) and limit the flexibility to experiment. Not only does it take away the limelight from the self-organised teams but also almost makes them extinct when it comes to decision making.  

• The Hardening sprint – A notoriously misused phase within the SAFe framework is the Innovation or IP sprint. Although it has a fancy name, teams or enterprises often use it as a hardening phase for the increment, mainly for bug fixing, pipeline issues stabilization etc. I have often seen hardcore agilists rant about this and question the very purpose of this phase. According to some, where incrementing features is fundamental to Agile and Scrum, this framework completely bypasses the same. This can occur in organizations who do not have a robust DoD (Definition of Done) both at team levels as well as enterprise level and are often overlooked at the retrospectives for the sake of meeting deadlines.  
• Not for start-ups – Since SAFe is predominantly a large enterprise agility scaling framework, it may not suit a situation like a start-up, especially if the whole set up is less than say 30-40 people strong-- typical of any start-up company. Applying SAFe techniques in such a scenario may reduce the flexibility to react quickly in a volatile market. 
• May seem Anti-Agile? – Ken Schwaber himself, has had a dig at this, questioning some of SAFe’s strategies, like the necessity for turning it into a product and licensing it, charging people to use it, adhoc tooling partnerships, etc. A few other agile practitioners believe that the SAFe framework is just too ‘complete’ to help the Agile culture of a company thrive, regardless of its size; unlike Scrum, which sticks to the true values & principles of agile and is left intentionally ‘incomplete’ in order to allow opportunities to adopt new values.  In a way SAFe can hamper the “Individuals and Interactions” aspects. 

Enhance your abilities with accredited PMP courses and elevate your project management expertise. Register today!
 

Conclusion:

If your head is spinning right now, don’t worry, it's absolutely OK to be in that mind state for a moment, considering that implementing SAFe is a major decision for any organization and should not be taken lightly. It will involve a significant amount of effort, training time and of course cost. Understanding SAFe may prove to be a gargantuan task, but it is a necessity to understand the framework correctly. My suggestion is simple. If you want to implement SAFe, please go ahead, but do not rush it. Take it one step at a time and follow the SAFe implementation roadmap. This roadmap (depicted in the diagram below) is a very useful strategy and charts out some critical moves which are needed in order to achieve organizational change.

Any major decision like whether to implement or not to implement SAFe is almost likely to be very contextual. I am sure the adoption of SAFe is only going to increase as enterprises turn to something that is readily available to adopt and will definitely open up their cheque books for SAFe and its partners. However, the key would be in trying to understand and measure what impacts it is resulting in.  Measuring some of the key aspects & business outcomes (like cycle time, release frequency, NPS, key business metrices like customer retention etc.) will be critical along with the adoption of SAFe. Remember, similar to the hurricane effect, SAFe is a storm in the current industry climate and is sure to take us all on a whirlwind tour. The trick is to be smart and have a peek into the eye of the storm, in order to reap the benefits and lay out strong foundations for the future of agile scaling at enterprise levels.  

Thanks for your patience and wish you all the very best in your Agile journey. In case you want me to write about any specific topic, please feel free to comment below and I’ll be more than happy to add them to my ‘Blog Backlog’. If you liked the article, please do share it among your agile community to help spread the word.  

Hope to see you soon, with more such interesting topics.