Agility at Scale

There are three levels, or dare we say levels of scale, for “agility at scale”:

Agility at Scale Circles


All three levels are important.  As you can see in the diagram above they build on, and support, each other.  Let’s examine these three fundamental levels for agility at scale:

  1. Tactical agility at scaleTactical agility at scale refers to the application of agile and lean strategies on IT delivery teams.  This includes the ability to apply agile on teams of all sizes, on teams that are geographically distributed, on teams facing regulatory compliance, on teams addressing a complex domain (problem space), on teams applying a complex technologies, on teams where outsourcing may be involved, and combinations thereof.  Figure 2 below summarizes these scaling factors.  An important implication of this is that because you are likely to have IT delivery teams facing different situations, these teams will be following different tailorings of the Disciplined Agile framework – context counts.
  2. Strategic agility at scaleStrategic agility at scale refers to the application of agile and lean strategies across your entire organization.  From an IT point of view this includes the majority, if not all, of your IT delivery teams as well as a the IT-level teams support activities such as enterprise architecture, operations, support (IT help desk), portfolio management, IT governance, and other capabilities.  From an enterprise point of view this includes all divisions and teams within your organization, not just your IT department.  Figure 3 below overviews how agile scales both tactically and strategically and Figure 4 overviews the Disciplined Agile process blades.
  3. Lean enterprise.  A lean enterprise is able to anticipate and respond swiftly to changes in the marketplace.  It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces.  Lean enterprises require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.

Figure 2. Complexity factors of the Software Development Context Framework (SCF).

SDCF Scaling Factors


Figure 3. Tactically and strategically scaling your agile delivery process.

Agility at Scale v2


Figure 4. The Disciplined Agile 2.x framework.

Delivery Lifecycles

Program Management

Release Management

Data Management

People Management

Product Management

Portfolio Management

Enterprise Architecture

Reuse Engineering

IT Governance

Continuous Improvement

Disciplined Agile IT

10 thoughts on “Agility at Scale

  1. Pingback: Agility at Scale Landing Page | Disciplined Agile Delivery

  2. Steve Orr

    This promises to be interesting. I always saw agile as being on a continuum of best (or at least, better) practices. As agile merges with many well established techniques for enterprise level software developments, will we get to the point where the word agile becomes unnecessary?

  3. Don O'Neill


    Is the “Agility at Scale” model simply focused on the endeavor domain and the team, way of working, and work? Where does the customer and solution domain factor into the “Agility at Scale” model?

  4. scottwambler

    @Steve, better/best is determined by the context of the situation. Although on most of the goal diagrams, see , we do indicate an ordering of potential practices these are only suggestions. We may find that X is generally better than Y, but recognize that in some situations X is a spectacularly bad idea whereas Y isn’t.

    On the issue of the word agile being unnecessary, I suspect that day will come. When agile becomes truly mainstream we won’t be throwing the term around as much. For example, when was the last time you heard any real debate about UML or object-orientation? Both of those strategies have become part of the landscape. Agile is on the same path.

  5. scottwambler

    @Don, as the first and third figures imply, the potential focus is on the entire organization. Of course, this will depend on the desires, culture, and needs of the organization.

    The focus of our work right now is on the IT aspects of the model.

  6. Reinhard Patels

    @Steve and @Scott – I think Agile brought nothing really new but a revival of GOOD and even ESSENTIAL practices that the traditional world eliminated over time by “streamlining” everything into pure sequential and seemingly completely plan-able project and program structures. We just gave them a fresh paint.

    Because really, planning and working WITH your team, the consideration of individual strengths and weaknesses, that your team members and employees are your greatest asset that you need to maintain and groom, that you should have quick and meaningful status meetings several times a week and honest feedback sessions with your team(s) at regular intervals and after essential milestones, … – all that and much more is not new. I did it already in the 80s. And I know of others, who respected such principles already in the 70s and 60s.
    That the waterfall model was never meant to be a pure sequential approach (the original feedback loops between the phases were deliberately eliminated over the years) was almost completely forgotten, and got a new life and look now in the various Agile/Scaling models.
    Relative estimation I did already with my very traditional teams and programs. Function Point and Feature Point approaches helped much and prepared the ground for many things incl. object oriented development and also relative estimation.
    When I started my engineering life it was absolutely normal to compile and link any changes that I did in a matter of minutes and test them right away.

    The only new thing that we did introduce with Agile was the combination of all these good old principles with the advantages of Rapid Prototyping – the iterative development, which consciously moves us away from having to know “all” the requirements and to have a “complete” design across everything before we can actually start implementing.

    And everything we do now with Scaling – all we have to do is to look at a company or organization as a team of teams. The real trick remaining is the identification of the real teams in this structure (as there are so many “virtual” teams definitions in a larger organization, that you often don’t see the real teams anymore, and al these virtual teams do a lot of sometimes even redundant and conflicting work, and we forget or simply miss to define the decision making authority for every single case/combination), and how to share single resources with several teams. Then – how we organize and run a team – we know pretty well in most cases.

  7. scottwambler

    @Reinhard, there’s a lot more to it than that. Everything that you say is a good start, but unfortunately the strategies you describe aren’t universally accepted, not even within a single organization. Consider Figure 4 for example. If each of the Plan/Build activities corresponded to a team, which they often do, each of those teams are very likely to have their own vision of what needs to be done, how it should be done, and why it’s the most critical activity within IT. Each of these teams will have their own cultures, philosophies, and collection of “best practices”. At least this seems to be what happens when these teams are left to their own devices to organize themselves, which is often the case in most organizations. For example, it’s quite common to see a data management team to have a very different culture than the operations team, which has a different culture than the reuse team, which has a different culture yet again from the portfolio management team. Getting these efforts in sync can be very difficult, yet that is what is required if you’re going to scale effectively.

  8. Pingback: What Makes a Good Disciplined Agile Delivery Coach? | Disciplined Agile Delivery

  9. Pingback: Agility at Scale Landing Page | Disciplined Agile Delivery

Leave a Reply

Your email address will not be published. Required fields are marked *