[Editor's note: This article was updated on June 22, 2015.]\n"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 ..." \u2013 Kent Beck, \u201cExtreme Programming Explained: Embrace Change,\u201d 1st Edition, [Publication date: 2000]\u00a0\nThese days, some software teams have hundreds of programmers. Many of them are on multi-year projects and working on ongoing programs \u2013 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.\u00a0\nAgile 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.\u00a0\nEnter Dean Leffingwell\u2019s SAFe \u2013 the Scaled Agile Framework \u2013 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\u2013100 people. [Note:\u00a0SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.]\n[Related: Why agile skills are more valuable than certifications]\n \nReproduced with permission from \u00a9 2011-2015 Scaled Agile, Inc.\u00a0\u00a0All rights reserved.\n\nSAFe in one image\nTake a look at the above image. Called the "big picture\u201d 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.\u00a0\nHistorically, 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.\u00a0\nA 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 \u2013 the company is buying one specific thing. This is the "small project" the executive talks about.\u00a0\nA 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.\u00a0\nAll aboard the release train\nIn SAFe terms, the \u201cRelease Train\u201d is the team-of-teams, typically 50\u2013125 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.\n[Related: 8 enterprise software predictions for 2015]\nThe 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 \u201chardening sprint\u201d (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 \u2013 something new program teams need to make the release train successful.\n \nRelease planning activity makes real progress possible.\n\nEach release train (remember, that\u2019s 50\u2013125 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 \u2013 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.\u00a0\nAfter 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.\n\nCrappy code can\u2019t scale\nOne 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.\u00a0\nSAFe 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 \u2013 as team one's priority and blocker will probably be team two's "nice to have."\u00a0\n[Related: 5 hot trends in software development hiring]\nAt 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" \u2013 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.\u00a0\nWhere 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.\u00a0\nNow 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.\u00a0\n\n\t\n\nSAFe 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 \u201cAgile and Lean Program Management,\u201d 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."\u00a0\nIs SAFe the end, or the beginning?\nIn his 2013 blog post \u201cUnSAFe at any Speed,\u201d 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.\u00a0\nReading 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.\u00a0\nOne 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.\u00a0\nThat 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.\u00a0\n[Related: IT Certification Hot List 2015: 10 that deliver higher pay]\nSAFe 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."\u00a0\nWith a half-dozen certifications, the Scaled Agile Academy aims to provide something for everyone. From two-day courses like SAFe Agilist (for management) and SAFe Practitioner (for people who are a bit more hands-on), to the four-day program consultant and then full-blown consultant\/trainer program, SAFe offers plenty of opportunity to earn credentials.