How ‘agile’ is SAFe?
Like everyone else in this industry, I have heard and read a lot about SAFe, Dean Leffingwell’s Scaled Agile Framework. Its popularity is evidence that there are many people who love it and swear by its effectiveness, but it also has its detractors. Some think it has its merits but needs to be used with care and consideration, while others think it’s ‘suffocating’.
Well, last week I had the opportunity to take the Leading SAFe 4.0 classroom course. What follows are my personal thoughts on SAFe.
What I like about it
Firstly, I like that SAFe considers agility at the Enterprise scale, with multiple portfolios of initiatives and hundreds or thousands of people working to deliver against them. I also like that it takes a Lean view at the portfolio and value stream levels, and that it considers and encourages the existence of an architectural roadmap to enable business capabilities. I also like that it has a way of prioritising these different types of work, and I like that it is based on the work of Don Reinertsen. I particularly love the transition to lean-agile budgeting, instead of project cost-accounting.
What I don’t like as much
You can read elsewhere about what other people think about SAFe, but the things I don’t like about it are these:
- The so-called Agile Release Train. Mostly, I just don’t like the name. I mean, it’s basically not a release train at all, it’s a Planning Train. The cadence in SAFe is all about alignment of planning, not of releases; we are encouraged to “release any time” that shippable solutions are ready and the organisation is ready to receive them.
- The 8 to 12 week planning cadence. As I understand it, this PI cycle is specifically to “make waiting times predictable, limit batch sizes to a single interval, to provide scheduled integration points and to control injection of new work” (all from the course notes). That sounds like our batch sizes are limited to whatever we can do in 8 to 12 weeks. And if demand for a new feature misses one PI planning day, it needs to wait until the next before it is planned and work can start, and anything from 10 to 24 weeks before it is released. Not particularly lean or agile at all, that.
- One too many layers. The big picture identifies four hierarchical layers of agility, each with specified roles, backlogs and terminology. This, in my opinion is one too many, even for the largest organisation. The difference between a Program (also a very poor choice of term) and a Value Stream is simply that the latter comprises more than one ART, and considers the supplier in the value chain. I like that layer. It’s the program one I’m not sure about. Combine them.
- Meetings. If your organisation is operating at the Value Stream level (and applying SAFe rigidly as suggested), you have a half-day pre-planning meeting to plan your planning, 2 full days with hundreds of people doing planning, and then another day of post-planning. That’s a lot of man-hours spent planning. And I haven’t even mentioned the demos and retrospective meetings at all levels. My feeling is that, like everything else painful, we should be doing this more often and in smaller chunks.
- An iteration specifically for Innovation and Planning. Wait, what? We suspend development for two weeks in every 8 to 12 and we… innovate? Firstly, ideas and innovations happen all the time; specifying a time for innovation to happen is ludicrous. And planning? Right before two whole days of planning? Enough already!
- Business Objectives. No, it’s not that I don’t like business objectives, they’re great; but SAFe says that we need to identify the business objectives for the PI and assign values (1 to 10) to each only on the second day of PI planning, after the teams have drafted their plans and identified risks and impediments. Never, in all of agile history, has so much cart been placed before so much horseshit (if you’ll pardon the expression).
My overriding impression of SAFe is that it is geared towards predictability over agility. It’s all very well quoting Lean and Value Streams and Cost of Delay, but when you only plan in (most likely) 8 week cycles, it doesn’t leave a lot of flexibility for change. It is cited as a good way to “integrate Waterfall and Agile projects”, which sounds to me like a destination no-one should want.
It goes into such detail as to suggest agendas for the planning sessions, and yet it makes no mention whatsoever of what to do when the business want to change priorities mid-Increment. Apparently, they need to wait for the next PI.
Don’t get me wrong; it’s not all bad. The case studies are generally from organisations adopting agile via SAFe, rather than scaling an already agile organisation. And this may be where the sweetspot is — it appeals to those used to large-scale projects and programs that value predictability over responsiveness. The Value Stream layer, introduced in version 4.0 of the framework, should, in my opinion, have replaced the Program layer, not added to it. It has resulted in confusing terminology and another layer of bureaucracy I am not sure is really necessary. Version 4.0 feels like it has taken a step forwards in terms of agility but hasn’t quite got rid of the old large-batch, project and program thinking completely yet. I look forward to SAFe version 6.0 or 7.0 when the entire framework operates on Lean principles with more frequent — and simpler — alignment and integration, and the words project and program are banished.