Last week I’ve had the pleasure of taking part in a Leading and Implementing SAFe course. During this four-day course I would be introduced to the Scaled Agile Framework, learn how to implement it, and learn how to share it with others.

To summarize the outcome of course in just one line: it sucked.

How is SAFe a framework?

To me, a framework is a light-weight set of boundaries within which there is a lot freedom to do as one sees fit. If you see the SAFe Big Picture you’ll understand my initial skepticism at the term ‘framework’. Nonetheless, I was looking forward to having my skepticism rebuked and to learn how to see and use SAFe as a framework. All this in order to be able to better help organizations that need scaling scale.

Whether organizations actually need scaling or a scaling framework is an interesting discussion. I think that if you need scaling you should first look at your products and your architecture. Self-organizing teams with the help of a clear vision and a good architecture can get a long way.

Unfortunately, the way I interpreted the way SAFe was put down this week was as a methodology. These are small selection of some of the concerns I have after having taken the course.

Let’s start with the roles: Release Train Engineer, our “facilitating” Super Scrum Master; Release Management, the Super Product Owner of the Release Train; System Architect, who together with the RTE and PM act like the steering committee of the Release Train (also, drawn above the teams, like hierarchically superior). All set and ready to go, all required.

The format in which work should be sent to the teams is also set for you: User Stories coming from Features or Enablers, coming from Epics; Enablers that are used for work supporting other User Stories or Features; and if you open the Value Stream level there’s something called Capabilities as well. Additionally, there’s a selection of templates available for most of these items to fill out. All having been done during the course and available from ScaledAgile’s website for your day-to-day use.

My biggest concern, however, was the ‘Agile Release Train’. Calling a Release Train ‘Agile’ when the recommended time-box is 10 weeks is beyond me. Sure, teams could release more frequently (and I quote, because of “individuals and interactions over processes and tools, and stuff”). But once you’ve seen the monstrous PI planning board with all its dependencies between teams you may wonder how that could ever happen.

In other words: my skepticism was not only not rebuked, it was definitely reaffirmed and has even worsened.

SAFe the way I would have liked to see it

If SAFe really is a framework, I would have loved to see it like that. Perhaps with a various complementary practices that would make it work for specific scenarios, in which alternatives to certain practices would have also been discussed.

The power of SAFe to me is keeping synchronized across teams and Release Trains in a larger organization, in which each release train is an independent part of the organization focusing on a specific product or value stream. There would be direct contact between the customer(s) and the teams in each release train, where each release train would have their own tools and practices to handle how work comes in. Whatever works for the teams should be the practice, not whatever someone else tells them to.

I love the end-of-increment Inspect and Adapt opportunity, but without all the practices that SAFe introduces and without the compulsory interval of 8 to 12 weeks. It’s great to inspect and adapt with a bunch of teams working on the same product or value stream, serving the same customers. Just like the PI planning: a high-level “planning” event which can be used to identify dependencies and remove them on the spot. I’d call it PI refinement rather than planning and I would never give commitment to finishing a list of work or reaching certain objectives for the next 10 weeks. I’d be doing my customer a disservice in nailing down what we’re going to do for 10 weeks rather than giving them the opportunity to take a different course at a shorter interval. But I like the synchronization nonetheless.

I’d have loved to see SAFe as an enabler for Agile at scale, because that is what organizations need. Practices come from experience and that’s where coaches come in: to help an organization find a practice that works from them, in which there is multiple practices to be compared. That is what SAFe (or any other scaling framework) should enable.

Closing

Looking at this constructively, I see SAFe as an intermediary step for very large and very traditional organizations towards true agility. I think it’s loads better than sticking to a waterfall-approach and if an organization implements SAFe the way I heard it, they’d be far better off.

To reach true agility you’d need to take a lot of additional steps. Mostly you’d need to experiment, see what works for your organization, your teams, keep inspecting and adapting and changing things if they make more sense. And to me, that’s the danger of a methodology over a framework: it makes things fixed rather than up for change. Whereas a framework should give you those boundaries in which your organization can shine.