Scrum Vs SAFe
I often see, specifically the new on-boarders of Scrum, trying to figure out the difference between Scrum & SAFe. I will try to explain this difference here in a very simple, lucid & concise way, Reason – I want it easy for the new boarders to grasp & not many of us like reading very long articles
Let’s start with the definitions, in our own words
Scrum is an iterative method of product development that focuses on a regular cadence of delivery. It relies on cross-functional teams, set of ceremonies & some specific supporting roles to help drive these deliveries.
SAFe stands for “Scalable Agile Framework.” It defines an approach for scaling Scrum to make it work for bigger enterprises that has much bigger teams working on the same product then what Scrum recommends
To summarise we can say Agile is a way of working, a mindset. Scrum is a framework, which claims that it is based on the Agile values and principles. SAFe is a scaling framework to implement scrum at enterprise level.
A big challenge with Scrum is in scaling it to larger and more complex projects that require multiple teams and also integrating it with enterprise-level management functions such as program management and overall product/project portfolio management.
Two popular methods emerged to facilitate this: the scrum of scrums, and the Scaled Agile Framework (SAFe). Both are great starting points for scaling agile within an organization.
When several scrum teams work together on a large project, scrum of scrums is the natural next step for scaling agile. The main component of scrum of scrums is a multi-team stand-up. This is not a status meeting. It's a short meeting, usually 15 mins., with ideally a technical representative from each team. This meeting helps keep people informed across the Organisation.
It will open doors for knowledge-sharing and surface important integration issues.
Scaled Agile Framework (SAFe):
Another way to scale agile in large organizations is SAFe. SAFe takes a more structured approach to scale agile than scrum of scrums. SAFe describes three levels in the organization: portfolio, program, and team. This structure goes good with larger organizations as it applies a tiered approach for the delivery of work.
Some constructs or terminologies in SAFe are Agile Release Train (ART), Release Train Engineer (RTE), Portfolio backlog, PI planning etc. I will leave the rest for your interest to explore and would try to conclude with a table of difference, indeed not exhaustive.
Deals with small collocated teams
Deals with big multi geography teams
Scrum is to the Agile team
SAFe is to the Agile enterprise (Extension of Scrum)
Middle management has no say/role
It deals with Program & Portfolio management
Basic construct is Scrum Team
Basic construct is Agile Release Train (ART)
Hello - I have just posted my small research & thoughts over here to help those who are still trying to find an answer to this simple query Scrum Vs SAFe. My humble start :)
Thank you, for the quick points and the difference between SOS and SAFe.
What is your view regarding Nexus vs SAFe?
Lemme come back to you on this :)
Thanks Abhishek. The information is cool for getting started. But the only major reason that I can figure out by going through your write-up is that we move the SAFe from Scrum so that:
1. The multi-scrum team sync is better.
2. Geo-location barriers are managed better.
3. And a major one that the product is too big to be managed in scrum so we decide to go a level up.
Please correct me if I am wrong anywhere.
Just by making an observation, SAFe works on several levels, they are: Team, Program and Portifolio. So if you wanted to compare "pure Scrum" with SAF and you should look at SAFe at Team level, the Team level still have some "scaling" stuff , but much less than at Program and Portfolio levels and here you can have some to compare.
Now if you want to get a view of scaled teams (which is SAFe's main proposal) you should look at the SAFe Program and Portifolio levels and "compare" with the Nexus (Scrum Scaled Framework from Scrum org).
Also remembering that the core of SAFe and Nexus are very similar (Scaled Agile Framworks) but both have some very different nuances and proposals and often it is not possible in a simplistic way to compare to say who is better, being the ideal here would be to evaluate among these proposals which best suits your company.
I like to say that it is very similar to that "fight" of what is better Java or C#, the answer is not "X is better than Y" a good answer will be "the one that suits you best in context."
@Elcio is correct. You are comparing two things that are not equivalent. I am also going to point out that SAFe is a Scaled AGILE Framework. It is not Scrum. It can use Scrum at the team level but it is not required. It uses some of the Scrum concepts but so do a lot of Scrum-but agile implementations.
While I can appreciate your effort and the time you took to write this up, I respectfully say that your assessment is not accurate or complete.
It would be interesting to hear your assessment of comparing SAFe with Scaled Professional Scrum (i.e. Nexus). That would be a more relevant comparison. But again it is comparing scaled agile to scaled scrum which is still not completely equivalent. They are based on the same empirical philosophy but are not the same.
Again @Elcio stated it well at the end of his post.
... the answer is not "X is better than Y" a good answer will be "the one that suits you best in context."
Exactly what Elcio and Daniel stated; one is not better than the other. Please don't focus on fitting in Scrum or SAFe because they are popular, focus on what works best for your situation. SAFe isn't the holy grail, neither is Scrum or any framework. Figure out what the needs are and what framework (if any) would work best.
I find that SAFe is built on agile values and that teams within SAFe preferably should work according to Scrum. The added levels are used to handle dependencies within and between teams/trains as is Scrum Nexus. Furthermore SAFe, to me, is a framework for business decisions where products are created or fundamentally changed. By using the concept of MVP to help make those decisions it differs from Scrum where small pieces of value are the way to go. For the viable part in MVP implies that the initiative (initiative as a general term and not the SAFe definition) is valuable in it self where as value from a Scrum sprint can, and mostly are, added value to a product that has been an MVP.
There is a real risk in implementing SAFe as a agile novice organisation because the different levels makes it possible to come up with big initiatives where small pieces of value would be possible and of course a much better alternative route. Then the organisations gets busy creating documents with requirements and a waterfall is created. The "MVP" later needs to be cut into smaller pieces to be handed over to the trains and teams. There in lies multiple risks of not slicing based on value, handovers, delays and more. Especially when coming from working in projects with requirement specifications it is difficult to take in the big leap into agile mindset and let go of the notion of planning and controlling. For this same reason I find that large agile novice organisations choose SAFe when starting the agile journey.
I don't understand what you mean by:
"By using the concept of MVP to help make those decisions it differs from Scrum where small pieces of value are the way to go."
Scrum Teams quite often use the concept of MVP as a matter of fact, the first Sprint will be an MVP and then the next will add more to it and so on...
Yes, I agree. But if the MVP takes longer time to build your business case needs to cover that investment including the uncertainties that comes with a bigger MVP. It is not something that I need or expect from an agile framework, but my reflection was just that SAFe do include it.
I have never worked on a product with Scrum that didn't define the MVP. Scrum doesn't look out only the current Sprint, you have a vision that drives what you are doing and more than a single Sprint of Product Backlog Items. Moving through you deliver pieces that deliver some value so that you can garner that feedback and keep learning, moving and delivering.
Agree with Eric
I too agree.