Introducing the Scaled Agile Framework™

Over the last few years, I’ve worked extensively with a number of other professionals (including Drew Jemilo, Colin O’Neill, Alex Yakyma, Mauricio Zamora) in the implementation of a number of large enterprise lean|agile transformations. This collaboration has resulted in many back and forth discussions around implementation of the Scaled Agile Framework™. To date, this framework has been elaborated primarily in my books Agile Software Requirements, Scaling Software Agility, and blog).

Recently, we decided to formalize our collaboration with the intent of making the framework public-facing and more readily available to a larger audience, and we have also committed to developing certain extensions and enhancements to the framework that have presented themselves as the marketplace, agile enterprise maturity, and our thinking and experiences have evolved. To that end, we will offer the Scaled Agile Framework (SAF) as a “proven, publicly available, framework for applying Lean|Agile practices at enterprise scale, presented in a structured, interactive, web format.”

I am extremely happy to announce that this initiative has been formalized and we are now “in development!” Over the last 3 days, Drew, Colin, Mauricio, and Alex have been camped out with me here in Boulder, Colorado, USA for our first Release Planning session (see Alex’s fun post on the topic).

SAF Collaborators - (from left to right) Colin O’Neill, Alex Yakyma, Dean Leffingwell, Drew Jemilo, Mauricio Zamora, in front of the Flatirons, Boulder, Colorado, October 21, 2011.

One of our first orders of business was to establish our identity as a group (About Us), agree on a common purpose (Our Purpose), determine the position statement (Product Position Statement) for the framework, and define a Roadmap for the first few releases. We accomplished these objectives in our first face-to-face sprint; the results are highlighted below and more information can be found at For now, the website is just an “Anticipate” landing page with a few auxiliary pages. The roadmap posted there illustrates that the first planned public release will be December 21, 2011. (As agilists, we will, of course, make that date).

Feel free to subscribe on the Scaled Agile Framework site (or here) and watch the work in process unfold over the next few months.

And of course, comments are always welcome.


— Dean

–Dean Leffingwell
Chief Methodologist, SAF Framework

— Mauricio, Drew, Colin, and Alex
Principal Contributors, SAF Framework



Through our collaboration, we hope the Scaled Agile Framework (SAF, pronounced “safe”) will:

  • Enhance the competitiveness, productivity, and delivered quality of the software industry worldwide
  • Help provide the business benefits of software agility to all software enterprises
  • Increase motivation, empowerment, and humanity to software development practitioners everywhere

And we surely hope to build good business value along the way!

 Scaled Agile Framework Position Statement

FOR software developers, practitioners, managers, executives, coaches, consultants, trainers, and agile working group team members

WHO are involved in planning and implementing Agile software development philosophies, principles, and practices at enterprise scale

The Scaled Agile Framework (SAF) is a proven, publicly available, framework for applying Lean|Agile practices at enterprise scale, presented in a structured and interactive web format.

UNLIKE proprietary methods promoted by product and consulting firms, or practices described in dozens of books

SAF is a synthesized, holistic, integrated, and summarized framework available to everyone in a readily accessible public-facing web site, including supporting resources.

7 thoughts on “Introducing the Scaled Agile Framework™

  1. Without a directed, mathematically grounded approach to partitioning, I don’t believe it is possible to scale Agile beyond a $1M project or so. There is no other way to deal with the complexity that will otherwise prevent Agile from being used successfully.

    • Roger,
      I’m not sure what a directed, mathematically grounded partition is, but it is absolutely true that this agile model scales, as I’ve been personally involved in succesfully scaling it to over 1,000 people in multiple enterprises, and 100-200-300 people in scores more. Others have too. You can look at the BMC case study for one such example. And while did not use this model explicitly, I was at a conference on Friday where their Dev VP recounted their experience in scaling agile to 1200 people. That case study is on my blog as well.

  2. Dean,

    First of all, let me say that I like the Agile methodology. So please don’t take anything I say as in opposition to Agile. My only concern about Agile is that the Agile community does not appear to have taken the steps necessary to achieve true scalability. Perhaps you have. There isn’t enough information here for me to draw a conclusion about that.

    Let me define “scalable.” In my mind, there are four criteria to “scalable.”

    1. The cost/time of the project should be linear with respect to project size (most are exponential.)
    2. We should be able to determine the minimum cost/time for the project before committing to the project.
    3. We should be able to deliver the project at the minimum cost/time.
    4. At the end of the project, the business should feel that their needs were met.

    Now I don’t know how you broke the large project down into sub-projects (i.e. “partitioned it.) I assume that you did it through decompositional analysis, since this is the most common approach. If so, decompositional analysis is essentially a pseudo-random process. Mathematically, it is described as a drunkard’s walk methodology, that is, it has many possible outcomes, few of which are optimal (criteria 2).

    Now it is possible that with highly trained folks leading the project, the decompositional analysis might have ended up with an optimal or near optimal result. But here is no way to test this with decompositional design. You can try to implement the system, but that only tells you the design is doable, not that it is optimal.

    And even if your highly trained group did succeed in finding a near-optimal solution, do we really want a methodology that depends on the background of those leading the project? Wouldn’t it be better if the methodology itself was reproducible?

    In other words, wouldn’t it be better if the methodology was directed? Directed means that there is only one possible outcome. Decompositional design is, as I said, pseudo-random; there are many outcomes.

    But being directed isn’t enough. Knowing the methodology is “directed” only tells you that there is one single outcome, not that that outcome is optimal. In order to achieve the one optimal outcome, you must incorporate a mathematical understanding of optimization. You could, I suppose, use a non-mathematical understanding of optimization, but I have difficulty imagining what this might look like.

    If you did all of this as part of a Scalable Agile pre-planning process, then you would have a truly scalable Agile approach.

    Now I should point out that this problem is not specific to Agile. It is a problem with all existing methodologies. This is why 95% of systems over $10M are considered full or partial failures. I pick on Agile because I believe it has so much promise in this area.

    Anyway, if you are interested in more on this, you might check out my white paper, “The Mathematics of IT Simplification” available at under the white papers tab.

    • Hi Roger and Dean,

      First, I’m enjoying the dialogue going on here between you both!

      Roger, as a software architect early on, and definitely still at heart, I’ve followed your work since mid/late 90’s (; heard you speak in Denver in late-90’s, when only a dozen+ braved a “heavy” snow storm, you rewarded us by giving your talk anyway, even when it was planned for 100-200 to attend. I’m familiar with your work and also Dean’s work as well and have leveraged his insights related to scaling agile methods.

      As a software architect (with a mathematical background) your SIP (Simple Iterative Partitions) concepts to guide (direct) toward “optimal” partitioning to “manage” complexity makes sense to me. I think you make a good point that extensive domain knowledge may be “guiding” some in their decomposition if it is being done w/o an explicit application of say the SIP process, and I also agree though this discussion is not limited to software development or agile.

      I also spend time studying the application of flow principles in the software development domain. In scaling lean-agile methods, I don’t think you can discount the contribution that limiting work-in-progress and a focus on flow makes in managing complexity as well. I think a “scaling model” that employs principles of flow that limits work-in-progress, creates a “tension” for completing work before ever starting yet more, and encourages smaller batches, helps to minimize/mange the number of concurrent dependencies (complexity). It doesn’t surprise me that scaling “agile” methods in a model/system that employs “kanban” methods at the higher portfolio levels has been successful.

      I’d love to get the three of us together for coffee and discussion, if you are ever in Denver… :>)

      Take care,
      Frank Vega

  3. Frank,
    Anybody who braved eight foot snow drifts (at least, that is the way I remember them) just to hear me talk is good to go in my book. I don’t have any plans to be in Denver, but we could set up a face-to-face on Skype or some equivalent. We could even have some snow blowing in the background just for effect.

    I think a discussion on bringing SIP and Agile/Kanban together would be quite interesting, and could result in a nice article/white paper. What do you think?

    My email is roger at the domain

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s