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 SAFe the Scaled Agile Framework a framework designed 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.

[Related: Why agile skills are more valuable than certifications]

SAFe in one image

Take a look at the above image. Called the "big board" 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 25-150 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 50125 individuals. Like a real train, the release train runs on a schedule, pushing code to production on a schedule (which I describe later as a Product Increment), typically every ten weeks. SAFe suggests that people involved in a release train be dedicated full-time to that release train, regardless of reporting structure.

[Related: 8 enterprise software predictions for 2015]

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 team (remember, that's 50125 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 technical role), 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."

[Related: 5 hot trends in software development hiring]

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. Eight12 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.

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. 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.

[Related: IT Certification Hot List 2015: 10 that deliver higher pay]

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."

Copyright 2016 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.