SAFe is a programming knowledge base that aims to enable you to apply lean-agile practices at enterprise scale. Will it take your development projects where they need to go?
By Matt Heusser
[Editor’s note: This article was updated on June 22, 2015.]
“Size clearly matters. You probably couldn’t run an XP (Extreme Programming) Project with a hundred programmers. Nor 50. Nor 20, probably. Ten is definitely doable …” – Kent Beck, “Extreme Programming Explained: Embrace Change,” 1st Edition, [Publication date: 2000]
These days, some software teams have hundreds of programmers. Many of them are on multi-year projects and working on ongoing programs – software that might have a shelf life of more than a decade. Those projects are complex, in-flight and with no easy concept of done.
Agile software development methodologies, in which individuals, interactions and cross-functional teams are valued over processes, comprehensive documentation and set-in-stone plans, have been nothing if not disruptive for big companies used to tight controls on developing the custom software they need to run their business.
Enter Dean Leffingwell’s SAFe – the Scaled Agile Framework – a framework designed by Scaled Agile, Inc. out of Boulder, Colo. to allow large organizations to move toward a more agile way of working. By large we mean more than a thousand people in IT, and more than 250 in software development, though it can be just as effective for teams of 50–100 people. [Note: SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.]
Take a look at the above image. Called the “big picture” within the company, it presents all of SAFe in one picture. The portfolio vision sketches out epics, strategy and value streams. The program level, where 50-125 people at a time work on a specific program, is well-represented. Below the program level is the team level.
Historically, scrum, extreme programming and other agile methods tend to focus, and stop, at the team level. SAFe presents a single, unified view of the work to executives, allowing them to drill down for details or up for trends and analysis.
A team in SAFe might be 8 to ten people, with everything they need to deliver software, end-to-end: requirements, coding, testing and deployment. Several teams create what SAFe calls a release train, which organizes around a program (more on that below). That’s a single project, or at least, one program-of-projects. It has a single line item in a budget – the company is buying one specific thing. This is the “small project” the executive talks about.
A portfolio is a collection of these programs, the total amount of budget dollars within IT going into software development. SAFe calls this “Program Portfolio Management,” and suggests that one office have the responsibility for strategy and investment funding, program management and funding.
All aboard the release train
In SAFe terms, the “Release Train” is the team-of-teams, typically 50–125 individuals. Like a real train, the release train runs on a schedule, though that schedule can be as flexible as your organization needs it to be. This Program Increment (PI) is described in more detail below. SAFe suggests that people involved in a release train be dedicated full-time to that release train, regardless of reporting structure.
The release train supports a long-term program that may have many teams and projects inside of it. The teams synchronize, lining up sprints and releases, so the code can be deployed at the same time for each increment. Older versions of SAFe suggested a “hardening sprint” (or two), not for testing within teams as much as for coordinating interfaces between teams. It might be best to think of the hardening sprint as a transitional step – something new program teams need to make the release train successful.
Each release train (remember, that’s 50–125 people) meets once at the beginning of each release cycle to develop Program Increment Objectives, and the team-level objectives that make the increment objectives possible. The meeting is typically two days long. In addition to simply planning, the meeting has other benefits, like allowing the team to have a sense of team-ness – to create the face-to-face conversations that make real progress possible. The meeting include representatives from both business and technology; over the course of the event the two groups merge and align, again reducing friction and errors from misunderstanding.
After planning, the team works on the next program increment (PI), and a small team needs to steer, or coordinate that work to success. SAFe calls that the release management team, which typically consists of the Release Train Engineer (a program facilitator, chief scrum master for the train), Product Management, and a few executives who are not committed to that program full-time. It may also include development managers, senior testers, architects and other roles on the program that could give input. This is the group that communicates with external groups on timing, and takes corrective action when there are schedule problems. SAFe suggests that the group meet weekly.
Crappy code can’t scale
One of SAFe’s public claims is that “crappy code can’t scale.” To avoid crappy code, SAFe suggests a handful of practices that are aimed more at prevention than traditional test/fit testing. SAFe starts with Agile Architecture, a principal that architecture is emergent, but the system architecture needs to evolve ahead of the newest features, to make adding those features possible. It includes continuous integration, having the software build and automated checks run for every check-in. SAFe advocates test-first as a philosophy, not just unit tests but also at the specification level. This practice of creating concrete examples, down to the inputs and expected results as a collaborative, whole team effort is called Acceptance Test Driven Development in SAFe.
SAFe also includes classic extreme programming practices like pair work, not just for programmers but for many roles, along with refactoring (improving the design of existing code) and collective ownership. Collective ownership of code gets more complex with multiple teams, but it also means that teams can make corrections instead of creating a “ticket,” or “make-work” for another team. This prevents the first team from being blocked and also does not create priority problems for team two – as team one’s priority and blocker will probably be team two’s “nice to have.”
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.
SAFe also supports different cases for release schedules: releasing on the PI cadence, releasing less frequently or releasing more frequently. While the development cadence is 10 weeks, release can happen at any time. 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.
One advantage of SAFe is how easy it is to transition to. You “just” train key implementers, leadership, management, and the team in a few days then flip a switch, in a manner of speaking. While obviously there’d be a lot more to do for the adoption of Lean-Agile development, the new structure can accommodate managers, directors, architects, analysts and every other role, with no need for painful transitions or job changes.
That leads to a concern that SAFe is a transitional step, just the first and least painful. In a continuously improving organization, the steps six months or a year after a SAFe transition are unclear.
SAFe may be a good step, and an improvement, for a large organization, but the cookie-cutter approach will only get you so far. After that, the organization needs to figure out what improvement should happen next, and that requires context. Agile coach Yves Hanoulle puts it this way “For most of these I would say, SAFe goes further as they are ready to go, not far enough as they should go.”