Method Wars: Scrum vs SAFe

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

1. 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.

2. 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.

3. 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.