A few weeks ago, I went on the SAFe SPC course, and passed the exam which means I'm a fully qualified, newly minted SAFe Program Consultant. I thought I'd give you a quick rundown of the course and my impressions of SAFe now that I'm apparently some kind of SAFe Jedi master.

For those who have been living under a rock for the last few years, SAFe (Scaled Agile Framework For Enterprises) is, as the name suggests, a scaling methodology for enterprise agile adoption. It is, to put it mildly, somewhat controversial, with many deeply in love with the methodology and some very strongly against it for many reasons. In the interests of full disclosure, I should say at the outset that I went into the course as someone pretty much on the anti-SAFe side. There were many things about the methodology that I didn't like, but I'm a big believer in giving things a fair go, so when the chance came up to go on the course, I figured I'd give it a go and let the other side have its say. So... what was it like?

First up, it was long. Really long. 3 full days packed with powerpoint slides then a day of Q&A plus the exam. So many bullet points. So, so many. This could have been a real death by powerpoint but our trainer, Mark Richards from Context Matters (Australia's only local SAFe trainers) pulled off a heroic performance to keep the group engaged and learning. The course materials are all standardised so he had limited scope for changing things round but he managed to keep us all awake.

After the course, we sat the SPC exam. I'm not a big fan of exam-based certification. I passed the exam which means I'm now a certified SPC and am entitled to teach some of the SAFe courses (everything except the SPC). Is a course and exam enough to make me competent to teach the material? Hell no! I may be able to pass a multiple choice exam on the material but that's very different to knowing it deeply enough to teach it well. This is the big problem with exam-based certifications - being able to pass an exam means that you know enough to answer a few multiple choice questions. It doesn't mean you actually know the material (or will remember it in a few weeks). I much prefer competency based certification. As far as I'm concerned, exam based certs aren't worth the paper they are written on.

That's enough about the mechanics. What about the methodology. Have I drunk the SAFe Kool-aid? No. Am I a SAFe-hater? Also no. There are some things I like about SAFe, and some things that I don't.

The big takeaway is that SAFe is more than just the big picture. You know the one. It's the front page for the SAFe website and gives an overview of the SAFe methodology. This is the the bit that everyone has seen, and to many people it's the whole of SAFe, but behind the big picture is a lot more detail. A lot of the objections to SAFe that I went in with were answered, at least in part, by the material behind the big picture. If all you have seen of SAFe is the big picture then you haven't seen SAFe. Dig deeper. A lot of the negative commentary on-line is clearly coming from people who have only looked as far as the big picture.

What did I like about it? I liked the focus on Lean. The whole methodology is based on Lean principles which is excellent. I like the fact that continuous learning is built in. There are still some things I don't like. Normalising story points across teams to me is a very bad idea. I'm not convinced by the reliance on the PSI cadence (the primary planning cadence in SAFe, about 12 weeks). I'd much rather see a focus on continual planning rather than batching work into PSIs. The concept of a hardening sprint (gone in the latest SAFe version thankfully) in any context other than a temporary aberration with an acknowledgement that its there because we just aren't good at getting things really done yet and will be removed as soon as we are, is very poor practice. But other than a few things, SAFe is a pretty good place to start an enterprise transition.

My big problem with SAFe is that it's really easy to interpret SAFe as a place to stop rather than a place to start. Mark (and all the other SAFe folks) stress that the big picture is a starting point and that continuous learning is built in, but big organisations have a real need to see "the recipe". The one best way to do something. They are looking for a place to stop not a place to start. The SAFe big picture feels to me like something big enterprises will treat as a stopping point.

SAFe also relies on some pretty heavyweight chunks of process. The primary planning increment is a 6 sprint chunk called a PSI which is planned in a 2 day, all hands (100 odd people in one room) planning meeting. I worry that after we have spent a lot of time and energy demolishing the waterfall edifice, once the dust has settled and the smoke has cleared, SAFe will leave us with a bunch of heavyweight things (like PSIs) baked into our new process that will take a lot of time and effort to get rid of before we can move forward. I would rather see an agile adoption that doesn't rely on heavyweight artifacts.

The fact that there is so much bad commentary about SAFe out there from people who haven't looked further than the big picture leads me to suspect that SAFe is a really easy methodology to get wrong. It's really easy to turn SAFe into a heavyweight, up-front driven, waterfall-lite type of methodology. SAFe really, really needs to be coached. By a real SAFe coach who knows their stuff well (not someone who has attended a 3 day course and sat an exam).

To me, SAFe still has too many process smells for me to be really comfortable with it. It's a good place to start, but not such a good place to finish. The SAFe big picture is its greatest asset - a fantastic pitch for big enterprises who want the agile recipe, but also its greatest liability as it is very easy to see it as a finishing line rather than a starting point.

I prefer an enterprise agile approach based on principles and patterns which allows the enterprise to develop an agile approach that works best for them, rather than applying a pre-canned recipe. And that, dear reader, is what I'll be talking about next time.