Method Wars: Scrum vs SAFe
Last week Ken Schwaber made a blog post that was highly critical of SAFe (the Scalable Agile Framework):
It's fairly hard-hitting and so I'd like to elicit other people's opinions about this, and to establish if there is any sort of consensus on the matter within the scrum.org community. I stated my own opinion and observations in the following post, though I am far from decided:
Dean Leffingwell has responded to Ken's post, in which he (unsurprisingly) defends SAFe:
Whether the Scrum community agrees or disagrees, it's fairly clear that SAFe isn't going away any time soon. It's also quite clear that it is being positioned as a wider framework that (for want of a better word) "subsumes" Scrum.
I therefore recommend that everyone on the forum considers the various aspects of this debate.
Ian, thanks for interesting links. Has the discussion been continued?
btw: Scrum works on team/feature level. Apart from SAF what else can be use to "embedded" Scrum on higher/ business level?
You don't really need anything else.
If you look at books like "Practices for Scaling Lean & Agile Development" ( http://amzn.to/18gfbWJ ) the common theme is that the piece you need to embed Scrum and the lean-agile practices you are looking for is not going to come from more rigour heaped on top of the scrum framework.
If you are not getting lean-agile principals embedded at a high level that would indicate a lack of desire for adoption and change at that level. This is normal and there is no formula to engender those ideals. One can use SAFe to give the organisation the same... mechanics that teams sometimes achieve with Scrum, but mechanics are not principals.
There is no formula, but creating Communities of Practice and introducing your executives to workshops in lean-agile principals can help 'flip the light-bulb' on for many... others will never get it...
It may be that the best you can do for now is SAFe to get everyone going in the same direction. You do however need to watch out for the illusion is a successful adoption that it can often create.
There's still some activity in the comments sections of those links. Also, I asked Johanna Rothman for an opinion and she certainly gave one, check out the comments section here:
SAFe isn't the only game in town. There's Disciplined Agile Delivery, but that's even less agile and far more blatantly RUP-like.
DSDM is credible as a framework for agility at scale, but it's artifact-heavy.
Oops, I've neglected to cite one other framework for agility at scale, and it's an important one. That's the Lean Startup approach developed by Eric Ries.
Although it is frequently associated with "garage startups" and incubator projects, the Lean Startup movement has evolved rapidly beyond that, and is now making inroads into the boardroom. It doesn't have the push behind it that SAFe does, but I reckon it's the one to watch:
- it is more compatible with the precepts of Scrum than other scaling frameworks
- it embraces disruption
To understand this, see Alex Deborin's response to Ken's post, and Ken's acknowledgment and validation of Deborin's position:
My preferred Agility at scale frameworks/ideas are:
Larman's Large Scale Scrum:
His ideas captured in these books(the books are too long though, IMO -- they really only read well for advanced practitioners, IMO):
Cohn's _Succeeding with Agile..._
Schwaber's _The Enterprise and Scrum_
The Scaled "Amateur" Framework, in its current form, is not ready for prime time IMO... and I'm not sure it ever will be because I'm not sure Leffingwell and Shalloway get it. I like them both personally because they are passionate process wonks like me -- but I think their bias is towards "what sells." I'd rather they focused on "what actually works" and/or "what is still in line with Agile principles that deliver Business Agility". They along with Scott Ambler are Agile outcasts... and I think there is a good reason there. I don't think the reason is jealousy or protection or anything like that.
I'm not speaking for Scrum.org, but I think we in the Scrum.org community would welcome any of the above 3 into the Scrum.org community if we thought they "get it"... and I'm pretty sure the Scrum Alliance would do the same. There's a reason that has not happened.
All of the above in my post is my personal opinion.
> I think their bias is towards "what sells."...
There is an irony here. If an enterprise framework can be seen as a product, then SAFe advocates appear to have been listening to what the product ownership is saying. They are clearly filling a market demand, and - here's another irony - they have done so in a market-disruptive way.
With the greatest possible respect to Ken Schwaber, Craig Larman, and Mike Cohn, they *appear* to have been caught sleeping on the matter of agility in the enterprise, or perhaps resting on laurels previously earned, and hoping that Scrum would carry naturally at scale. We all share the blame for this. None of us have yet produced a satisfactory alternative to SAFe that fits the demand it has plainly validated.
Without a satisfactory response, it's fairly clear that the likes of SAFe and DAD will continue their encroachment into the boardroom, following well established channels to market. Our terms of reference may end up belonging to different owners. When that happens, who is and is not an agile outcast might become painfully apparent.
Ian, I 90% agree with you, though Agility Path (https://www.scrum.org/agility-path) + Scrum is certainly an alternative to SAFe for scaling approaches, IMO. I will concede that Agility Path is later to the market, and more enigmatic so far.
My only other thoughts are that
Maybe they were resting on laurels or not... but they certainly didn't get to market as fast or as "pretty" as the SAFe folks.
IMO, Larman's work is outstanding, just not packaged or "sold" as well as the others.
Having said that, they certainly deserve credit for the packaging and selling -- very well played, and the market will reward them handsomely I'm sure.
As a later follow up to this thread, here is a collection of people who have deeply evaluated the SAFe(tm) approach and have found numerous problems with it.