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 not 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.
Original Agile within SAFe

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.


I've been at my job for fifteen years. That's a third of my life. You do the math! I've always loved computers, since the earliest days of middle school, when I was exposed to the 8-bit computers of the 1980s: The TI-99 4A, the [Atari 400][Atari400], the [Commodore VIC-20][VIC20] and [64][C64], and of course, at school, [Apple\]\[s][Apple2] everywhere. After graduating from high school in the eighties, and taking a couple of college courses at [St. Pete College][SPC], I took a wide variety of [in-house software][InHouse] development jobs for local companies, did a couple years worth of [self-employment][linuxtampa] during the peak of the [Dot-Com bubble][dotcom], and as every techie above a certain age knows primally, it burst at the end of 2000. My little consulting business ended at that time too. During a 15-year stint in Corporate America, I have learned tons about the big-corporate approach to software development, from: * learning how to do just about ANYTHING in Java (because, ENTERPRISE!) * writing documents that (almost) no one reads: * High-level Design Documents * Detailed Design Documents * Test Plan Documents * Release Notes Documents * provisioning my teams' REAL development environments from discarded rack servers and Dell Optiplex and Inspiron PCs. * navigating the 'unofficial' social inter-departmental paths to Getting Things Done. * and last but not least, dodging at least ten rounds of layoffs. Don't get me wrong: there are a few things I'm really proud of too: * Introducing [Subversion][svn] as a standards-based source control in my team (2011) leading to company-wide adoption. * Being the first in the company to pioneer [embedded Jetty-based J2EE development][jetty-embed], to remove the typical compile/package/deploy/unpack/reload cycle, and make my developers far more productive. * Being the first to introduce both [jQuery][jquery] and [AngularJS][angularjs] as far superior web development technologies to Oracle ADF and Adobe Flex. * Helping a large-volume traffic analysis system based on [Oracle][oracle] scale far beyond a billion rows per day, by replacing the RDBMS in [Vertica][vertica]. (in hindsight, it should have been [Apache Hadoop][hadoop]). * Helping our operations team migrate dozens of applications from Solaris to Linux. But the software world is evolving so much faster than that. * Git has completely trounced Subversion in functionality and mindshare. * More virtualization choices than ever. It's not just Xen, VirtualBox, VMWare, etc. Now we've got OpenStack, Docker, AWS/Rackspace/VPS, Puppet, Chef, Ansible, oh my! * Linux is far more capable than ever too, but you wouldn't know it if your organization will only use old RHEL releases still on the 2.6 kernel. Now, I want to improve Free/Open Source Software ITSELF. [Atari400]: https://en.wikipedia.org/wiki/Atari_8-bit_family#The_early_machines:_400_and_800 [VIC20]: https://en.wikipedia.org/wiki/Commodore_VIC-20) [C64]: https://en.wikipedia.org/wiki/Commodore_64 [Apple2]: https://en.wikipedia.org/wiki/Apple_II [SPC]: http://www.spcollege.edu [InHouse]: https://en.wikipedia.org/wiki/In-house_software [linuxtampa]: http://linuxtampa.com [dotcom]: https://en.wikipedia.org/wiki/Dot-com_bubble [svn]: https://subversion.apache.org/ [jetty-embed]: https://wiki.eclipse.org/Jetty/Howto/Run_Jetty#Embedded_Startup [jquery]: https://jquery.com/ [angularjs]: https://angularjs.org/ [oracle]: https://www.oracle.com/database/index.html [vertica]: http://www8.hp.com/us/en/software-solutions/advanced-sql-big-data-analytics/index.html [hadoop]: http://hadoop.apache.org