Benefits of the Scaled Agile Framework

For those who have not yet heard of it, the Scaled Agile Framework, or SAFe® for short, is a “publicly available framework for applying lean/agile practices at Enterprise scale.”

I believe that the SAFe model offers a number of benefits to those who may be considering its use. Let me enumerate them.

1. It is publicly available and free to use.

While the SAFe materials are protected by copyright, with restrictions that prevent others from modifying the materials or redistributing them, the entirety of SAFe is available at ScaledAgileFramework.com, along with the permissive statement that “all enterprises and practitioners can use any of the concepts and ideas on the site, and even implement the framework know-how described on the site, free of charge.”

2. It is available in a highly approachable, usable form.

The framework is available as a website, with a diagram on the home page (“The Big Picture”) that shows all of the key deliverables, roles, activities and flows, and also serves as a navigational aid to the rest of the site. In general, the site is only one level deep: the user clicks from the Big Picture to a page providing brief definitions and explanations, and then goes back to the home page.

3. It is lightweight, in the best sense of the term.

Unlike the CMMI®, or ITIL®, or other somewhat comparable industry frameworks, this is not a massive tome that requires years of dedication to master; each graphic on the home page takes you to a single web page, consisting of a quotation or two, a graphic or two, some key definitions and concepts, and then reference links to additional details that can be found in some other (generally more comprehensive) sources.

4. It is practical.

Unlike some other industry frameworks, which are more generalized, — in the sense that they offer you guidelines for process development, rather than processes themselves — the Scaled Agile Framework is immediately usable by practitioners. Its target audience consists of people doing software development — not people helping others write processes about how to do software development

5. It is specific.

SAFe offers specific terms, concepts and practices to be used by software developers. Whereas other frameworks have taken the direction of ever-increasing generalization and abstraction, SAFe is specifically focused on how to use agile and lean practices to develop software.

Note that because it is specific, it is somewhat more controversial than other, more generalized, process frameworks. One may not like the CMMI, or find it useful, but it is hard to argue with it, because it is so abstract that is hard to take exception with any of it. The Scaled Agile Framework, in that sense, is not playing it safe — instead, it picks sides and places bets. This aspect of the work makes some people uncomfortable, but arguably it also makes the work much more useful for those who are more interested in developing software than in debating methodologies.

6. It conveniently codifies some of the most common agile practices in use today.

As examples, definitions for “agile teams,” “product owner,” “scrum master” and other common terms and concepts are represented on The Big Picture, with definitions and explanations just a click away.

7. It offers useful extensions to common agile practices.

Most agile practices in common use today are based on Scrum and/or XP, which are really focused at the practitioner and team levels.

SAFe extends the agile model up to the program and portfolio levels. It does this by, again, codifying many elements in common use today — things like the the hierarchy of epics, features, and stories — but also by adding novel yet useful concepts, such as the idea of the “Agile Release Train,” the term SAFe uses for the Program level equivalent of Agile Teams.

8. It grounds agile practices in an enterprise context.

Many agile models are really very developer-centric — they seem to depict the entire development process from the perspective of a developer, or a development team.

SAFe still leverages all of the by now traditional elements of agile, and yet it also places software development realistically in the context of an enterprise that is served by such teams. As one example, SAFe acknowledges that estimates will need to be done at the program and portfolio levels, based on definitions of epics and features, before descending to the level of granularity needed for stories and story points. This is sometimes viewed as sacrilege by agile coaches and practitioners steeped in team-based practices, but it is a necessity for doing agile at scale within the context of large organizations.

9. It offers a complete picture of software development.

Roles of Enterprise Architect and System Architect are included in the model, as are the concepts of Architectural Epics, Architectural Features and Architectural Runway. UX experts and DevOps teams are given roles to play. Product Managers are included as well as Product Owners. Non-Functional Requirements are included in the model.

So while the SAFe model is relatively simple, it is not simplistic. It includes all the elements that are actually needed to develop and deliver software in a modern enterprise context.

10. It is regularly maintained.

Ongoing SAFe development seems to moving along at a good clip. While there have been no drastic changes that would cause distress to early adopters, there has been a steady pace of ongoing progress and polishing. SAFe is now at version 3.0, and a preview of 4.0 is available. So the SAFe team seems to be releasing one new version per year. And ongoing evolution seems to be based on actual experience using the model in the field, rather than on abstract theorization.

In Summary

So there you have it — ten reasons to give serious consideration to the use of SAFe within your enterprise!

I documented my reservations about the CMMI back in 2008. While I doubt that Dean Leffingwell and company have read my blog post on that topic, they do seem to have systematically gone down my list of reservations and addressed them all one by one.

Back in 1992, Edward Yourdon wrote about the original Capability Maturity Model, “Until you can find a better map, this one sure beats wandering through the forest in the dark.”

Two decades later, I think it’s time to say something similar about the Scaled Agile Framework: it may not be perfect, but if you’re trying to implement agile within a large organization, it’s better than wandering through the woods on your own.

March 21, 2015

Next: Agile Project Planning