BY Anshuman Singh | January 2, 2017

[Total: 0    Average: 0/5]

Since the arrival of Scaled Agile Framework in the world market, there have been comparisons ad nauseum between the Scrum and SAFe® frameworks.

Many industry experts have come out and pointed possible flaws in the Scaled Agile Framework. For instance, Ron Jeffries has expressed reservation over SAFe®’s approach to resolve inter-team dependencies by holding a multi-team meeting comprising of over 250 people (Dependencies & SAFe®).

Ken Schwaber has mentioned that SAFe® does not adhere to the Agile Manifesto values (especially the first tenet – Individual and Interactions over Processes and Tool) as it is highly process-centric (UnSAFe® At Any Speed).

Is SAFe Agile

However, the Scaled Agile Framework indeed subscribes to the ethos of the Agile manifesto. Those who have undergone any initiation to SAFe® would confirm that at Team level, SAFe® works very much like standard Scrum, although the teams can also work in Kanban.

At this level, we have an Agile team that is cross-functional and works together to deliver working software every 2 weeks (or 4 weeks as per the discretion of the teams) – which are called Iterations. The content for the Iteration is determined by a Product Owner who is in-charge of the Team backlog.

The Iteration starts with a planning meeting where the team decides what user stories they can deliver by the end of the iteration. Each day the team discusses their progress and at the end of the iteration, they Demo the results to the Product Owner to ensure they have delivered what the Product Owner had wanted. They then get together to retrospect where they can improve for the next iteration before starting the cycle again with a new Planning meeting. All of this is guided by a Scrum Master who makes sure the team works smoothly within the process and that the team also works together to keep improving the process.

In the context of SAFe®, you have multiple Agile teams working independently but in sync. By implication, all teams need to have the same Sprint start date, end date, and duration. This is a key tenet of SAFe® framework and referred to as ‘Develop in Cadence’ in the big picture. Thereby, the basic atom comprising the SAFe® molecule is a Scrum team. The aggregated increment of multiple Scrum teams is the ‘feature’ that has been planned and agreed to be released with the Product Owner (PO) beforehand.

Scaled Agile Framework - for Lean Software and System EngineeringImage credits: Scaled agile 

Check out our SAFe® tool  SwiftEASe.

Principles of Agile and Continuous Delivery

Perhaps, the reason behind the success of Scaled Agile Framework is its ability to bring in the concepts propagated by Continuous Delivery and DevOps. As a result, SAFe® has been adopted more rapidly than the older methodologies like DAD (Disciplined Agile Delivery), LeSS (Large Scale Scrum) and Nexus. SAFe® stresses the need to integrate all the Scrum teams’ ‘increments’ at the end of the synchronized Sprints. This ensures that the Software is maintained in a releasable state always. Hence, the motto of ‘Release any time’ is a key tenet of SAFe® framework. In agreement with the key tenets of the Agile manifesto, software is developed in ‘chunks’, maintained in a working state and regular releases to the market bring in the customer feedback needed to improve the software in future increments.

Scaling Challenges in Large Programs and Organizations

With all the good things that Scrum teams have been capable of, there has always been the nagging – scaling challenge. The perennial question – How to scale Agile? The need to scale has been felt in scenarios where a bigger increment is needed or a large program has to be delivered in an Agile manner.

Also, many companies in transitioning from the traditional Waterfall method to an Agile one, seek a proven framework that would help them scale up while adhering to the Lean-Agile principles. Large organizations which have been operating for a long time and may have a variety of processes and micro-cultures across different teams and now want to implement Lean-Agile principles are more likely to look for something “tried and tested” than seek their own approach to scaling. They might use the SAFe® blueprint (or even one of the others such as DAD or LeSS) – not just to Scale Agile but to carry out a deeper organization-wide transformation. In the process, they might well tweak the framework to the way it would work best for them.

Going by the large number of organizations we have come across, Scaled Agile Framework or SAFe® has provided a template for scaling agile principles and tools to large organizations. SAFe® is a framework meant to cover the entire organization. It operates on 4 levels – Portfolio, Value Stream, Program, and Team.

Is SAFe® Agile?

The Agile manifesto at no place mentions the ideal team size for the adherence of its principles. Hence, it would be contentious to state that Agile cannot be scaled. Also – going over the Agile manifesto, the principles do not state ‘how’ to practice Agile. Nor do they recommend any best practices. Agile principles serve as a guiding star pointing to the end goal. They can be taken to scale encompassing bigger numbers of functionaries to collaborate in a creative fashion with the aim of achieving a common goal.

Scrum is a framework that assimilated the Agile manifesto ideas and created a blueprint comprising of Roles, Artifacts, Events and Values that organizations or teams that intend to practice Agile principles of software development can conform to.

The commonalities between Scrum and SAFe® frameworks are that both are inspired by the Agile manifesto. The heart of a successful SAFe® operation is multiple successful Scrum teams developing and integrating into cadence. It is unfair to compare the two and is akin to comparing leaves on a tree to its entire branch. SAFe® brings together the key principles of Scrum, Kanban and Continuous Delivery to offer a framework that does not view all these concepts in isolation but coalesces them with the end goal of working software firmly etched – in alignment with the Agile manifesto.

Perhaps, the most likely reason that SAFe® feels “not Agile” is its overall content, structure, and size. It appears to go against the grain of the Agile Manifesto’s tenet “Individuals and Interactions over Processes and Tools, as Ken Schwaber pointed out! Yet, the fact is that as many enterprises attempt to coordinate and synchronize the output of its various teams to cohesively produce tangible products and services in an orchestrated manner, they have looked for some overall prescription – a framework – with which to be able to do so while.

Is SAFe® Agile? What do you think? Please share your comments/ experience with us!

Checkout our tool SwiftEASe which helps in Scaling Agile with SAFe®, please follow this link:

Anshuman Singh
Product Manager, SwiftEASe

SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Leave a Reply

2 Comment threads
2 Thread replies
Most reacted comment
Hottest comment thread
3 Comment authors
Anshuman SinghKotiRichard Lynn Paul Recent comment authors
newest oldest most voted
Notify of

I think the scrum is a way of implementing single team agile and SAFe is a way of implementing large scale agile (multiple team agile) and hence both have their own significance and yes SAFe is agile for sure. About using scrum in SAFe, it totally depends upon what kind of work we are scaling. Based on the nature of the work, technology, release time lines and other factors we may chose, Scrum or any other frameworks. So there is nothing like pros/cons or comparisons needs between Scrum and SAFe and they are neither complimentary and contradictory. People try to… Read more »

Anshuman Singh
Anshuman Singh

Absolutely, the whole essence of Agile is in the ‘being’ and not in the ‘doing’. The framework(s) by themselves are not the end goal or the answer. They provide the team an opportunity to initiate discussion, reflect and reform. I like how simple practices such as daily stand-up (regular communication) or making work visible (increasing transparency) can have profound impacts on how teams function and think. The ceremonies and the roles play a key part in a team being Agile – both Scrum and SAFe seem to have that. However, a blind practicing of these is not correct and a… Read more »

Richard Lynn Paul
Richard Lynn Paul

It seems like the great idea of agility (being agile) has been commercialized into doing agile, which is good, but not better or best, that is, not the ideal. Doing agile will not give as many benefits as being agile. All the talk about being able to creatively come up with a solution with the customer, rather than just pumping out little pieces to get feedback after-the-fact (after release to production).

Anshuman Singh
Anshuman Singh

For a team to have an Agile spirit it does need a place to start from. The framework(s) are probably enablers that seem to give teams (that are new to Agile and haven’t been exposed to that way of working) a reasonable place to start from. It is for the team to eventually weed out the unnecessary and build up on what suits them or even introduce new constructs. As you have stated – it should eventually lead to an imbibing(realization) of the key principle – Customer Collaboration over Contract Negotiation and not just post-de-facto analysis/meeting. How to get there?… Read more »