Agility at Scale

What does it mean to scale agile?  The answer to this question depends on who you ask.  For example, some people will tell you that scaling agile means applying agile strategies to a large software development team or to a geographically distributed software development team.  To others scaling agile means applying agile strategies across a lot of software development teams and to others scaling agile means you apply agile strategies to your organization as a whole.  It isn’t clear, is it?

This article overviews what it means to scale agile from a Disciplined Agile (DA) point of view.  To do so it works through the following topics:

  1. The Scope of Agility
  2. Agility at Scale
  3. Tactical Scaling – Scaling an Agile Team
  4. Strategic Scaling – Organizational Agility

The Scope of Agility

Scope of Disciplined AgileLet’s explore each aspect depicted in the diagram:

  1. Disciplined Agile Delivery (DAD).  DAD addresses all aspects of solution delivery from beginning to end, in a streamlined manner.  This includes initial modelling and planning, forming the team, securing funding, continuous architecture, continuous testing, continuous development, and governance all the way through the lifecycle.  The framework includes support for multiple delivery lifecycles, including but not limited to a basic/agile lifecycle based on Scrum, a lean lifecycle based on Kanban, and a modern agile lifecycle for continuous delivery.
  2. Disciplined DevOpsDisciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.
  3. Disciplined Agile IT (DAIT).  As the name suggests DAIT addresses how to apply agile and lean strategies to all aspects of IT.  This includes IT-level activities such as enterprise architecture, data management, portfolio management, IT governance, and other capabilities.
  4. Disciplined Agile Enterprise (DAE).  A DAE 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.  Such organizations require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.

Agility at Scale

The Disciplined Agile (DA) toolkit distinguishes between two types of “agility at scale”:

  1. Scaling agile at the team level (tactical agility at scale).  This is the application of agile and lean strategies on individual Disciplined Agile Delivery (DAD) teams.  The goal is to apply agile deeply to address all of the complexities/scaling factors (team size, geographic distribution, organizational distribution, domain complexity, technical complexity, and regulatory compliance) appropriately.  Scaling frameworks such as LeSS, NEXUS, and SAFe tend to focus around the issues of team size and sometimes geographic distribution.
  2. Scaling agile at the organizational level (strategic agility at scale).  This is the application of agile and lean strategies broadly across your entire organization.  From an IT point of view this includes Disciplined DevOps and Disciplined Agile IT in general.  From an enterprise point of view this includes all divisions and teams within your organization, not just your IT department.

Scaling Agile at the Team Level (Tactical Agility at Scale)

Tactical agility at scale is the application of agile and lean strategies on individual Disciplined Agile Delivery (DAD) teams. The following figure summarizes the scaling factors that will affect your efforts to tactically scale agile 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.  An important implication of this is that because you are likely to have delivery teams facing different situations, these teams will be following different tailorings of the Disciplined Agile toolkit – context counts.

Figure 2. Scaling factors of the Software Development Context Framework (SDCF).

Scaling Agile at the Organization Level (Strategic Agility at Scale)

Strategic agility at scale is the application of agile and lean strategies broadly across your entire organization.  From a high-level point of view this includes all four levels depicted in Figure 1 above, and from a more detailed point of view all of the process blades shown in the figure below.

Have any Question or Comment?

10 comments on “Agility at Scale

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?

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?


@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.


@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.

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.

Don O'Neill


What you have said is well said and needed to be said.


@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.


Leave a Reply

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