Consider these five very different types of organizations:

1.  An organization with fairly hierarchical management structure, traditional Project/Program Management Office (PMO) trying to transition from traditional waterfall development to agile development.  Some teams have just a few months of experience with Scrum, and perhaps worked with few XP or Lean practices.  Budgets are done on an annual basis.  Senior management pays lip service to agile transformation and treats agile as a silver bullet.

2.  A government contractor is used to delivering projects on a fixed-price basis.  The government agency has now asked the contractor to use agile methods for large-scale agile projects.

3.  The CIO and CEO of an enterprise are strongly committed to agile-lean development and have given a top-down marching order to follow agile methods.  All teams have been ordered to follow a two-week iteration cadence, while members of some teams come from an offshore outsourcing vendor.

4.  A company has found that their main competitor will be  The release cycle for most of its IT projects is six months, and they know that unless they drastically reduce this, Chapter 11 is not far away.

5.  A startup company realized that unless they validate their assumptions about who the real customers are, and what the real needs of real users are, they have no viable business.  They decide to follow the Lean Startup method by rapidly developing a series of Minimum Viable Products (MVPs) in rapid succession.  Even after the first release of the product, the company must stay ahead of competition and deal with rapid changes in market conditions.

With the vast diversity of organizations and their projects, a cookie-cutter approach (or prescriptive recipe for all types of projects and situations) will not work.  Each agile project developing a product or solution has a unique context: assumptions, situation, team members and their experience and skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.


Many agile development teams now have some experience of team-level agile practices using Scrum, XP, Lean, Kanban or Scrumban frameworks.  Some of these organizations have experience with Scrum of Scrums (that is, two to as many as nine Scrum teams working together on a product or solution). These teams and their organizations are now setting their horizons to undertake large-scale agile projects where several (10 to 1,000) teams must collaborate to implement the common vision of a product or a solution.

In the last few years, there has been increasing interest in scaling agile-lean methods beyond individual teams or Scrum of Scrums to programs and portfolios of teams, as well as being able to compose new applications by stitching together a set of services developed by independent teams.  The recent Agile 2014 conference had numerous presentations on the topic of scaling agile.  I attended as many of them as my schedule allowed, and caught much of the rest as recorded sessions.

Many of these sessions raised the issue of ‘which scaling agile framework is best?’ I came away thinking that every large-scale agile project creates a unique situation. To tackle this question, there are really two broad approaches you can take to select the right agile-lean process for your project:

APPROACH #1: Select a well-known, scalable agile framework listed below.

A. Scaled Agile® Framework (SAFe™) by Dean Leffingwell and his associates at Scaled Agile Inc.
B. Large-Scale Scrum (LeSS) by Larman and Vodde
C. Disciplined Agile Delivery (DAD) and Agility at Scale by Scott Ambler and his associates
D. Matrix of Services (MAXOS) by Andy Singleton

If necessary, extend or adapt or customize the framework to suit your unique needs. As you gain experience, inspect and adapt for ongoing refinements and further customization. “Scaling Agile Your Way” does not mean that each new large-scale agile project must develop its own agile processes from scratch.

APPROACH #2:  Develop a customized approach from scratch.

Or, if your project has truly unique needs that cannot be satisfied by any available framework (such as SAFe, LeSS, DAD, MAXOS) even after customization of the framework, you may need to develop a set of new processes from scratch customized to your unique needs, and then sustain and maintain those processes.

In many organizations, not many in-house people have this kind of expertise that would actually work.  Moreover, this approach would be expensive and may not be cost-effective.  As such, this approach to large-scale agile projects should not be undertaken on the ground of ideological purity, but should be based on solid business reasons.

It is important to state what “Scaling Agile Your Way” does not mean.  It does not mean that each team in a program is free to choose and optimize its own agile method, practices, cadence, release duration, metric and reports, etc., without any coordination with and consideration of other teams in the program.  If this were done, although each team may end up optimizing its own way, that may ignore what is good for the higher level program.  Similarly, optimizing at the program level without any regard to the higher portfolio or enterprise level is not “Scaling Agile Your Way”.   Those kinds of decisions (disregarding the system level optimizations and trying to optimize only at a subsystem level) might amount to “Agile my way or highway”, irrespective of Approach # 1 or # 2 described above.  Systems thinking is important for Scaling Agile Your Way.

This blog series is not a tutorial on or an in-depth review of SAFe, LeSS, DAD or MAXOS.  I will provide a brief overview of these frameworks for getting started.  I will then present a set of 25 scaling parameters (organized into 6 scaling aspects) that need to be considered to decide what scaling approach and methods are best suited for your specific situation, and what kind of customization will be needed.

SAFe: SAFe is a popular agile scaling framework for “enterprise-class,” large-scale agile projects.  It has great market momentum going for it, with extensive information available in the public domain, and training/certification programs from the Scaled Agile Academy and its partners.  SAFe is a proven and publically available framework for applying agile-lean practices at scale.  Many agile project lifecycle management tool vendors (such as VersionOne and Rally) support SAFe.  I will cover SAFe’s Sweet Spot, Challenge Zone and Unfit Zone, and give examples of how to customize SAFe for your situation in this blog series.

SAFe is often criticized, rather harshly and often unfairly, as being overly prescriptive and hence not suitable for many large-scale agile projects.  In some situations, SAFe is a good fit (Sweet Spot), while in some other situations, SAFe may be in a “Challenge Zone” where some effort (such as enhancement and customizations) will be needed to overcome those challenges.  But even with that effort, you may be better off using SAFe, compared to developing your own set of agile processes and practices from scratch.  However, in some situations, SAFe may be in an “Unfit Zone,” i.e., it is either not applicable or will not work well.  Full disclosure: I am a certified SAFe Program Consultant (SPC).

MAXOS: A relatively new agile-lean framework called MAXOS allows you to scale a particular type of agile methodology called “Continuous Agile,” where teams release working code several times in a day. In fact, after each change, the code becomes releasable shortly, thanks to automated testing, continuous integration, and developer-centric teams.  All teams continuously integrate their code into an enterprise-wide common code base, with a very large number of automated test sets running continuously in a cloud computing environment.  MAXOS is being used at many leading high-technology companies, such as Google, Amazon, Hubspot, and   MAXOS is particularly well-suited for large-scale Software-as-Service (SaaS) for consumer mass markets, and for lean startups (based on Eric Ries’ Lean Startup methodology).  MAXOS offers a radically different approach to scaling agile compared to SAFe.  MAXOS also has its own Sweet Spot, Challenge Zone and Unfit Zone, as I will explain in this blog series.  The Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS are very different.  The contrast between SAFe and MAXOS is breathtaking.   If your competition has started to use MAXOS and you are still using SAFe, your competition couldn’t be happier!  On the other hand, if you insist on using MAXOS in situations where SAFe excels, you would be making a poor decision.  Many practices from MAXOS (such as test automation and continuous integration) can be incorporated within SAFe.

At present, MAXOS doesn’t seem to have formal training and certification programs.  I attended MAXOS presentation by Andy Singleton at the Agile 2014 conference, and have reviewed most of the public information about MAXOS, including the eBook on Continuous Agile method.

LeSS: LeSS is regular Scrum applied to large-scale development.  LeSS is developed by Larman and Vodde.  A key message of Scrum is to avoid a cookbook of defined process. Realize that each team and each product will have to inspect and adapt their own Scrum adoption, which will evolve sprint by sprint. Therefore, the suggestions offered by LeSS are no more than that—suggestions.

DAD: DAD is a process decision framework developed by Scott Ambler and his colleagues.  The DAD is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, enterprise-aware, and scalable.  DAD leverages proven strategies from several sources (Scrum, Lean, XP, Kanban, SAFe, DevOps, Agile Unified Process or AgileUP, Agile Modeling, etc.), providing a decision framework to guide your adoption and tailoring them in a context-driven manner.

Although there are differences among SAFe, LeSS and DAD, those differences are dwarfed by their differences from MAXOS.  For example, while SAFe, LeSS and DAD are predicated on cross-functional teams with a number of meetings required, MAXOS advocates developer-centric, highly empowered teams (developers, not QA, decide to release!), and “management automation” to eliminate many meetings.  As LeSS and DAD are not as popular as SAFe at this time, I will not cover them further in this blog series.

You can use the Agile Scaling Knowledgebase (ASK) decision matrix to access a template for comparing SAFe, DAD, LeSS and other scaling agile frameworks.

SAFe and MAXOS cover a fairly large territory of vastly different types of large-scale agile projects.  Once you understand SAFe and MAXOS, and your own unique situation, you may be better off using one of those (with appropriate customizations as needed), rather than creating one from scratch and sustaining your own custom agile processes (an expensive and risky proposition).

There may be unusual situations where neither SAFe nor MAXOS may be a good fit for a large-scale agile project.  I will cover this topic in Part 3 of this series.  If you believe that your large-scale agile project has unique requirements that render both SAFe and MAXOS totally useless, and you have no choice but to create, maintain and sustain your own custom processes for your large-scale agile project, please let us know.  I would be very interested to know about your unique situation and what led you to prefer custom processes from scratch.

Customization approach:  Scrum at Scale (meta)-framework developed by Jeff Sutherland and Alex Brown starts with the basic premise that Scrum is an object-oriented framework.  Scrum at Scale framework is aimed at extending Scrum for large-scale agile projects, while retaining Scrum’s object-oriented architecture.  Scrum at Scale framework, along with its pattern library, are aimed at allowing agile projects to develop their own unique and customized methods for scaling Scrum to large-scale projects.  In Part 4 of this blog series, I will explain salient aspects of Scrum at Scale, and how its object-oriented approach may be used for customizing SAFe for your own unique needs.

Agile Scaling Aspects and Parameters:  Any large-scale agile project needs to consider a number of scaling parameters in order to decide which scaling framework would be most appropriate for its unique needs, or whether it needs a totally custom set of agile processes.  Table 1-4 shows a set of 25 scaling parameters, grouped into 6 scaling aspects:

1.  Teams

2.  Customers/Users

3.  Agile Methods and Environments

4.  Product/Solution

5.  Complexity

6.  Value Chain

The list is a fairly comprehensive, but by no means, exhaustive.  If some of the 25 parameters are not appropriate for your large-scale agile project, you need not consider those parameters.  If any scaling aspect or parameter is missing from the list, please let me know.  Each scaling parameter may take one more values from range of options. For example, “Number of teams” parameter associated with “Teams” scaling aspect has a value in the range of 10 to 1,000.  “Composition of teams” parameter associated with “Teams” scaling aspect can select a value in its range of options: Developer-Centric, Somewhat Cross-Functional with Guest Experts, or Fully Cross-Functional.  Multiple options can also be selected as long as they are not contradictory.  For “Composition of teams” parameter, only 1 out of 3 possible values can be selected.  On the other hand, for “Agile method of choice and required tool support” scaling parameter of “Agile Methods and Environment” scaling aspect (see Table 2), multiple choices are possible, such as Scrum, Scrumban, and Scrum+Lean.

Many of 25 scaling parameters are considered by ASK, DAD and Scrum at Scale frameworks.  Tables 1-4 use the following legend to indicate which scaling parameter is covered by ASK, DAD or Scrum at Scale.

  • A:  ASK
  • S: Scrum at Scale
  • D: DAD/Agility at Scale

Note that some of the 25 scaling parameters are not covered by any of these frameworks.  For example, “# 5. Composition of Teams: Fully Cross-Functional” scaling parameter is covered by all A (ASK), S (Scrum at Scale) and D (DAD); while “# 5. Composition of Teams: Developer-Centric” scaling parameter is not covered by ASK, Scrum at Scale or DAD.





As you review the information in Tables 1-4, you will realize that the “scaling agile” space is complex and very rich with many choices.  Each organization or a large-scale project is likely to select a different combination of these scaling parameters as relevant; moreover, the value or range of values for each scaling parameter for a project or an organization is likely to be unique.

What agile-lean scaling approach are you considering: SAFe, LeSS, DAD, MAXOS, or something else?   What are your customization needs, and does your selected approach fit well with those needs?

Part 2: Scaling Agile Your Way – SAFe vs. MAXOS

Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS

Part 4Scaling Agile Your Way – How to develop and implement your custom approach

Join the Discussion

    There are currently no comments.

    4 + 2 =