Agile Zone is brought to you in partnership with:

I'm Chief Scientist at proAgile Ltd. You could pretty much say that software engineering methodologies are my bag. I specialize in agile transformations at enterprise scale, and tweet and blog quite actively about this. I'm also the curator at Ian is a DZone MVB and is not an employee of DZone and has posted 37 posts at DZone. You can read more from them at their website. View Full User Profile

Method Wars: Scrum vs SAFe

  • submit to reddit
I hear the pitter-patter of a dinosaur.
 - Khloe Kardashian

This week, with the Agile 2013 Conference in full swing, Ken Schwaber - the originator of Scrum - wrote an excoriating blog post on the Scaled Agile Framework (SAFe). SAFe is meant to fill a gap that Scrum supposedly leaves and its advocates have been attending that same event.

The core thesis behind SAFe is that while frameworks like Scrum can work in the small, there are greater considerations that must be addressed before agile methods can function in the large. These issues include matters such as Program and Portfolio Management and Release Planning. SAFe is thereby positioned as a remedy for supposed deficiencies in the application of Scrum at enterprise scale. To say that Ken Schwaber is unimpressed would hardly do justice to his post. Ken's disdain for SAFe seems to be almost visceral. I hope they don't meet up at the bar.

If you smell politics behind this, you'd be right. It certainly isn't all technical. SAFe is aligned to the Big Method school of thinking, and owes much of its inheritance to the Rational Unified Process...although perhaps rather less so than Disciplined Agile Delivery. Anyway, from a Scrum perspective SAFe might be dismissed as the death-rattle of an essentially stage-gated and procedure-heavy dinosaur. It can be viewed as a reflex to agility, and not a species of it; a last-gasp relic from a prehistoric waterfall world.

Ken is therefore understandably suspicious when he sees advocates of the Scaled Agile Framework attending the Agile Conference. A "dinosaur" seems to be masquerading as a different animal in a desperate attempt to find relevance and to survive. As he wryly observes in one barb: "They are touting their processes and tools this week at Agile 2013 in Nashville. They would be at the RUP conference, but there are none. They would be at a waterfall conference, but they are no longer. So they are at our conference. Strange, but they had nowhere else to go. Try to be polite." Poor Scaley the Dinosaur! Give him a cheery wave as he sinks down into the silt, and step over his fossil nicely.

Ken expresses the concern that "Many organizations will open their checkbooks for SAFe and its partners". He's right. A few months ago I worked as an Agile Coach on the largest SAFe implementation in Europe. Although I have many years experience in agile transformation, it was my first experience of using this particular framework. My job was to coach the Service and Operations teams in agile ways of working so that they could be included in program management and release planning. As you might expect, I found that Scrum could be used in some cases and that Kanban was more applicable in others. Aligning these with each other is one thing. Bringing SAFe into the mix is another quite different dilemma.

I found that SAFe presents significant challenges to an agile enterprise transformation of this nature. Here are the top three:

  • Poor compatibility with Service and Operations teams. Those who provide technical support in an organization can't stop their day-to-day work to do release planning. At best they can send a representative and hope that this will be sufficient. Organizing a hiatus might not be a significant problem for engineering teams whose work on a backlog can be suspended by agreement with Business. However it is certainly a problem for people in first or second line support who are expected to provide ongoing coverage, often 24/7.
  • Technical debt. It was no longer expected that each Sprint had to produce an increment of value that was potentially releasable into a live environment. SAFe's use of hardening sprints is inadequate as a remedy; no matter how much you caution against it, it will be used as a sink for technical debt. For all practical purposes each Sprint lasted twelve weeks between releases. 
  • Normalizing story points between teams robbed them of control of their own process. Their metrics were no longer their own for the purpose of inspection and adaptation. Instead they were used by management, ostensibly to facilitate planning, but also with a view to comparing teams. There was a real danger of "point-productivity" becoming more important than the actual delivery of potentially releasable increments. SAFe's contention that "with adjustments for economics of location, (US, Europe, India, China, etc.), work can be estimated and prioritized based on economics by converting story points to cost" is hard to consider with a straight face.
Now, here's the thing. Despite these and other problems, the Scaled Agile Framework appeals to large corporations. It has currency in the boardroom and those checkbooks Ken wrote about are indeed being opened. In short, there is life in the old dinosaur yet. The reason for this is diabolically simple.

SAFe has gained traction not in spite of poor agile credentials, but rather because of them. Most organizations have only managed a patchwork approach to agile transformation. Teams rarely own their process. They face extensive dependencies and are unable to take a Sprint Backlog through to delivery without impediment. At scale, we're still in a waterfall world and a poorly implemented one at that. In fact, I'd say that most organizations demonstrate a stage-gated culture, and not the true application of any sort of process at all. That's why they look to SAFe. The barrier to entry is comparatively low.

Scrum, although simple in concept, is enormously hard to implement and it has not yet presented executives with a comparable transformation road-map they can buy into. Until that happens, Scrum will continue to be a small scurrying mammal dashing between dinosaur legs...and the dinosaur will continue to roar.

Published at DZone with permission of Ian Mitchell, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Ian Mitchell replied on Tue, 2013/08/20 - 9:28am

For the record, Dean Leffingwell - the founder of SAFe - has responded to each of the three points I made in the above article. Here are his comments...and I'll leave it to you to make your own minds up about what he says.

Let me see if I can address your big 3 in short order:
1. Attendance at release planning by people in ops and support, is of course, optional. If no one goes, then they have no idea what is upcoming, and no easy way to assure their items get proper backlog priority. If everyone comes then you’ve reduced support capacity for too long a period. Most programs have a person who attends as a proxy, bring their backlog priorities in advance to product management, and take away “stories” that are bound to sprint cycles, primarily for the reason of knowing what happens when and by whom.
2. If SAFe was interpreted as “no longer a reason to produce an increment of value at each sprint”, then it was interpreted badly or badly written. the Hardening, Innovation Planning (Please read that article again) sprint covers three things, not just the one. And it says specifically, “if you don’t need hardening, don’t do it”. I think we all agree that most teams shouldn’t need “hardening forever”, unless of course releasing requires, for example: extensive performance and reliability testing teams can’t do themselves, or 100 hours of field time (I mean field in the agricultural sense!) on a new, and only, prototype tractor, or final security protocol testing and sign off to meet information security requirements that are mandatory prior to release. These are all real cases. You have to be practical about these things. But if HIP is an excuse for technical debt; than you need to address that at the root cause. (Or simply implement SAFe with no HIP sprint. I’ve seen that done too, but then it runs into the types if issues I just described.). The Big Picture is just a typical pattern; not legislation. We cant possibly show every variant on one picture.
3. Velocities are NOT normalized across teams. Estimating is. If you don’t normalize estimating, then there is no meaningful economics; you can’t figure ROI of you don’t know that the “I” is. If you want to scale agile, and there is no meaningful way to bid work across teams, and within a program, you will be blocked before you even try (executive view: “That agile thing; not ready for prime time. They use gummy bears per sprint as their main metric, and they can’t estimate work in any meaningful way. They just don’t get it. I know, let’s just have the PMs do a work break down structure; that we understand. And of course, we’ll need good specs to do that, so let’s stop and write the SRS now”.) Then Agile loses.

Ian Mitchell replied on Wed, 2013/08/21 - 2:54am

Johanna Rothman - who many will appreciate as a blogger on DZone - has also weighed in on this. Here's just part of what she told me yesterday when I asked for her opinion. It's no less critical of SAFe than Ken Schwaber's recent post:

"Let’s be clear. SAFe is RUP. It’s not agile. Staged delivery is not agile either. Both of these approaches are much more effective than waterfall. (If we could get people to consider alternatives to waterfall, the world would be a much better place. This is why I wrote Manage It! Your Guide to Modern, Pragmatic Project Management.
Dean is a very sharp cookie, and he has discovered a way to management’s heart. Good for him.
But don’t call SAFe “agile at scale.” It’s not. It’s RUP at scale. It’s an excellent RUP at scale. But it is not agile. The time from a feature into the backlog to the time a feature is out of the backlog is measured in months, not weeks. That is a very long time. SAFe has hardening sprints. What’s agile about a hardening sprint?"

Johanna's full response, with the original context of my query, is here on her personal blog:

Jim Strange replied on Tue, 2014/04/15 - 9:18am

'you can’t figure ROI of you don’t know that[sic] the “I” is'

True, but story point estimation is a poor unit of investment. The only reliable common unit of both investment and delivered value is monetary.

If you want to plan the economics of an investment, then standard release planning is perfectly usable; then given a known (or estimated) team-specific velocity metric and a known (or estimated) cost-per-sprint for that team, the economics are simple. Assuming that normalising story points gives consistent economic modelling across multiple teams seems incredibly naive. But it no doubt appeals to the bean-counters.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.