The Agile Manifesto defines a set of principles to improve software development, by acknowledging that you do not, and will not know all the challenges that lie ahead.
In other words, Agile is a direct rejection of the old Waterfall and Big-Design-Upfront methods that dominated large-scale projects before. Of course, some shops are reluctant to give up the power that comes with such heavy handed disciplines. They want to be seen as ‘doing Agile’, but cannot bring themselves to actually do it. Enter “Scaled Agile Framework” or “SAFe”. Here’s an example top-level diagram of SAFe, with entire chart darkened, except for the original Agile portion. See that tiny little patch of white in the lower-left corner? That’s the original Agile methodology. So, what’s going on here with the gray part of the diagram?
Well, having been too-long exposed to a large corporation who invariabily thinks their requirements are extraordinarily special, I think I can offer a clue.
Agile requires that management lays off the command-and-control mentality too much, so from my typical Dilbert-esque cube farm, I think SAFe was, in part, concocted specificially for such old-school shops to SAY they are doing Agile, but without actually having to do anything of the sort. In fact, I think SAFe practioners are doing the exactly opposite.
Notice that the rest of the chart calls for multiple Agile teams working in parallel? Okay, fair enough. Companies usually have multiple projects in the hopper at any given time.
The next super-structure imposed on poor little Agile is the Program Increment. This is supposed to keep the multiple teams in sync, every 6 sprints (which are normally 2 weeks long), so effectively every three months.
Next, see how there is an Agile Release Train? I suppose the word ‘trains’ were chosen because 1) they’re fast, 2) they’re non-stop, and 3) it allows them to create tortuous-sounding position names like “Release Train Engineer”. And I kid you not, in the SAFe training book, there is an image of a person wearing an actual locomotive hat next to the paragraph that describes this role.
The idea of scheduling ANYTHING 3 months ahead, let alone on multiples teams at once, is about the most ANTI-Agile thing I’ve ever heard of.
Another unfortunate side-effect of SAFe (at least as implemented in this one case) is the mass-creation of positions of authority for people who crave such positions, because they are no longer capable of actually delivering code.
My colleagues and I had two days of SAFe training, delivered by a certified vendor in such things. Afterwards, we were encouraged to take the exam. I was pretty turned off by the whole experience, because everything presented just felt WRONG. I took the exam anyway. I was amused (but not surprised) to score 65% on the exam, and totally horrified to actually get the SAFe certification anyway. I don’t know how low the bar for ‘passing’ is, but apparently it is south of 65%.
No amount of ‘process’ can fix bad technology decisions, but these SAFe instructors and coaches seem to be selling their process as if they will cure cancer. From what I can see so far, it slathers on a new layer of cancer.
By the way, I specifically do NOT include “Agile” or “SAFe” on my resume. Not because of this bad experience, but rather because I fervently hope to see Agile done right in my next position.