A few months a ago a I successfully completed the Scaled Agilist Certification course and exam, for the Scaled Agile Framework (SAFe). These are my thoughts on SAFe.
A SAFe place
Agile (aka Extreme Programming) in a corporate environment is tough. Believe me — I've been there. The typical advice is to start small: pick an isolated green-field project, and assign a small Agile team. When well supported and executed, this approach can be highly successful. Sadly, these successes are often limited in scope and short-lived.
A single Extreme Programming team, in the corporate world, is vulnerable. I have seen succesful teams derailed by changes in mid-level management from the supportive (or won-over) to a more conservative and bonus-focussed personality. Changing business priorities and reorganisations can sweep away a small project team. Their environment is often hostile, so the team needs strong and politicly savvy leadership. Losing that leader can leave a team wide open to attack.
The Scaled Agile Framework takes an entirely different approach. Rather than dropping an elite team behind corporate lines, the approach is to train a conscript army and launch a mass assault on the waterfall. There's no pussyfooting around with pilot Agile projects: a SAFe implementation starts with 50 to 100 people screaming out of the trenches.
Basic Training for the Conscript Army
In this world the Scaled Agile Certification course and exam seems to correspond to basic training for the managers. While the "scaled" parts of the framework are covered, there is a lot of emphasis on teaching Agile/Scrum 101 (iterations, done-done, stories, velocity, etc... ) — no prior Agile experience required.
Lower expectations
An Extreme Programming story is finished when it is ready to release to production. SAFe includes "hardening" sprints to make double sure that its "Potentially Shippable Increment" is really shippable. There's no path to Continuous Deployment here.
Less threatening
While SAFe does drive a certain amount of decision making down to self organising teams, a hierarchy is maintained. Executives and Architects feed their "Epics" into the top of the system; they are managed through the Portfolio, Programme, and Team levels out to production. While the nature and title of some jobs may change, I suspect that everyone can stay employed and keep their status.
One of the harder things to convince the business about in an Agile adoption is the practice of releasing early and often. SAFe sidesteps this by defining Potentially Shippable Increments every few sprints — points at which the software could be released but is not necessarily released.
For an Agile and Lean process, though, this would seem to produce a very long feedback cycle between feature inception to release, making Hypotheses Driven Development next to impossible.
My conclusion
Rolling out a SAFe programme does seem to be a realistic way to bring some of the efficiency benefits of Agile Software Development to the corporate world, in a way that can stick. It is reasonable to roll back some expectations around quality and feedback cycles.
SAFe does have the concept of continuous inspection and improvement, but I fear that it would be hard to assail the prescriptive pillars of SAFe once it has been embedded in an enterprise. We would need to knock down at least some of those pillars to introduce the true innovation that comes with combining Lean UX and Agile Development.