At the portfolio level, SAFe is essentially looking at the IT organization's ability to deliver, and perhaps support/maintain, working software. The metrics that SAFe suggests are things like employee engagement, customer satisfaction (these may be internal), agility, time-to-market, quality and the ability to work with partners outside of the software organization. These terms may seem a bit light, or qualitative, but SAFe provides specific, clearly measurable meanings to each of these terms. Some of them, like quality, can clearly be "gamed" the presence of these metrics does not remove the need to manage the process. In addition to these hard measures, SAFe suggests burn-up charts to manage the process of an individual epic and a bar chart showing actual and to-be-done work to compare the progress of multiple epics at one time.
Where most agile development organizations focus at the team level, on sprints or iteration, SAFe focuses on the program, which could be five to 15 teams. The "program-level sprint" in SAFe is the Program Increment (PI), formerly known as the Potentially Shippable Increment (PSI). The goal of the PI is to accomplish the PI objectives.
Now we start to see the pieces of SAFe coming together: Release Planning defines the objectives for the Agile Release Train, which are built during the Program Increment.
The main criticism of the PI is the duration. Eight 12 weeks, or five two-week sprints, gives a lot of time between releases for feedback. This means the Release Train drives toward a few, large releases per year. Former Agile Conference Chair Johanna Rothman, and new author of "Agile and Lean Program Management," suggests that small batches are possible even within large program teams. As she puts it, "I want small releases every single day (if possible), and monthly if not daily."
Is SAFe the end, or the beginning?
In his 2013 blog post "UnSAFe at any Speed," Ken Schwaber argues that SAFe is essentially the Rational Unified Process (RUP) rebranded as agile, and that after the failure of RUP in the marketplace, the RUP people came to agile. Dean Leffingwell, the lead author of SAFe, was a senior vice president at Rational Software Corporation (now a division of IBM), and many of the contributors to SAFe do have a Rational or IBM background. One highly-placed source suggested that where the Agile Software Movement came out of practice, RUP, SAFe, and other methods were derived theory-first, not out of what has worked, but instead on what should work, based on models.
Reading the SAFe descriptions, however, gives a different impression. Most of the pieces of SAFe are familiar, borrowed from existing agile methods that work. The package and the organization may be new, but most of the pieces of SAFe are practices with some success behind them. The argument that SAFe derives from theory has less credence than the argument that SAFe is a transitional point sold as the end goal.
Sign up for CIO Asia eNewsletters.