Scrum Vs SAFe

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 :)

-Abhi

Thank you, for the quick points and the difference between SOS and SAFe.

What is your view regarding Nexus vs SAFe?



https://www.scrum.org/resources/scaling-scrum

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.

Scrum is a unique framework that insists accordingly to the basic agile methodologies, whereas the SAFe is a scaling framework that is helpful in implementing scrum along with Kanban ventures. Both the approaches are for the specific project management exploited in modern software development. These methodologies encourage the designated teams to support iterative and incremental work sequences, commonly named as ‘Sprints’.

Check this resource to know more in-depth: https://www.agilemania.com/blog/scrum-vs-safe/

Based on my experiences with SAFe, I am not sure it is Agile as was originally envisioned in in the "Manifesto for Agile Software Development" being that it is overtly over complicated. I would argue it fails on a few of the points below:

"We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more."

Now I am not saying SAFe Agile is not Agile - I just argue it is it's own version of "Agile" or agility not aligned to the above or the 12 principles behind them even. Organisations wanting to invest in SAFe need to be aware of this.

The highly simplified summary:

Scrum - team level agile framework, can be a building block of scaled agile

Scrum of Scrums - the oldest way of scaling Scrum, basically incorporated in all popular scaling solutions

Nexus | LeSS - Scaled Scrum for harmonising the efforts of multiple Scrum teams working on the same product. I think of these as detailed and formalised Scrum of Scrums frameworks.

SAFe - organisation/enterprise-level scaled agile where Scrum is a team-level building block (perhaps along with Kanban or any other team-level framework). Teams may or may not work on the same product. At the heart of the scaling, it uses the  Agile Release Train which is kind of a Scrum of Scrums. (I guess when teams are running on Scrum, working on the same product, Nexus and LeSS can fit into SAFe.) In addition, the scope of SAFe is way broader than software development. PI planning and the Agile Release Train definitely put some external constraints around Scrum.

Spotify-model - the squads, tribes, chapters and guilds provide different cooperation opportunities for teams and for team members with specialist skills. Squads can use any team-level framework, just like in SAFe. Can be mingled with other scaling approaches.

Thanks @Abhishek

Nice explanation 

Thanks. This is great!

When you get a deeper understanding of SAFe, you will realize that SAFe is NOT scaled Scrum.



SAFe takes concepts from different existing frameworks and methodologies and combines them into a meta-framework. Some people call it the frankenstein of frameworks, because they take awesome ideas and turn them into something that does not quite fit together and is disgusting, perverted. 



SAFe redefines the roles and meanings of the concepts its "integrates" - for example, a Scrum Product Owner and a SAFe Product Owner are VERY VERY different roles! 



SAFe also violates all agile and scrum values. it does not want to create transparency, because information is intended to only flow upstream, 



Scrum is focused on outcomes and has a strong belief in empowering people. SAFe is focused on maximizing the predictability of output (generating value is the lowest priority in the framework!),  and is build around the strong belief that people need to be controlled and managed. Whenever you look at SAFe implementations in the wild, there are usually very inefficient feature factories with lots of highly paid external consultants involved to "make it work". 

 

Scrum empowered the Product Team to take decisions - SAFe takes away all decision power and established a top-down command & control structure. As a result, it is basically anti-agile. 



Yes, you find all the fancy words in the guidelines – but when you see that they have changed the meaning of those words, you realize that SAFe is nothing more than a much more complicated way of doing waterfall project management.



The best quote to describe SAFe is

“War is peace.

Freedom is slavery.

Ignorance is strength.”

― George Orwell 1984

"P" stands for productivity in SAFe. 

Looking at all the processes and then to the Agile Manifesto, I see hardly Agile in there. In my opinion, it is popular because it is easy to just rename existing structures (or even add structures) in a company.