2

While SAFe is picking up a lot of attention and as I understand seems to yields better long term results (velocity and overall product quality) than traditional Agile, I'm curious about its possible downside. Any thoughts on this would be appreciated.

  • how would you quantify better results? Depending on what you mean my answer would change – Daniel Nov 30 '18 at 5:45
  • (I'll edit my question) @Daniel thanks for the precisions – Émile Bernard Nov 30 '18 at 5:53
  • What does "traditional Agile" mean to you? – Erik Nov 30 '18 at 6:18
5

First, I must say that my experience does not match the statement nor am I aware of any study that shows that. When SAFe or "pure" Agile are adopted well, they both have great throughput and quality.

When looking at the differences, I'd first look at what makes them hard to adopt well. With SAFe, there are many positions to be filled and it feels a lot like the old positions in waterfall, but they aren't. From a change management point of view, it is tempting to say that managers or team leads become release train engineers, etc. This is where a lot of SAFe adoptions fall apart because people do their old job, not their new one and they carry many of the old dysfunctions that the company was adopting SAFe to fix along with them.

With a more "pure" agile approach, the problem is the opposite (and paradoxically very much the same). Simplifying the organization and decentralizing decision-making is terrifying, and so many organizations simply don't. They put in some meetings and take a few terms from Scrum or Kanban and call it a day. Anyone in change management will tell you that a half-done change is a disaster.

You asked about a downside and I would point to this: what change is your organization actually willing to make? Both are a real commitment and neither should be half-done or you are likely to end up in a worse place than you started.

One other thing to consider: what are you optimizing for? SAFe was always designed for incredibly large projects. I don't mean 5 teams, I mean dozens or more. Scrum is optimized for rapid problem solving and adaptability (at a scaling level, LeSS and Scrum@Scale both keep this focus). Kanban is optimized for flow of work through a workflow. If you need to solve problems and adapt to a rapidly changing environment, SAFe might "work" but in the same way that you can hammer in a nail with a wrench if you need to. Similarly, I wouldn't try to manage massive projects with just a pure Scrum approach.

  • Thank you for your answer. It is both complete and easy to understand. – Émile Bernard Nov 30 '18 at 6:47
  • My main concern with SAFe was that as soon as you start "planning" 6 sprints in advance, you're already turning much less agile... – Laurent S. Dec 3 '18 at 14:48

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.