Project Management

Disciplined Agile Principle: Context Counts

From the Disciplined Agile Applied Blog
This blog explores pragmatic agile and lean strategies for enterprise-class contexts.

About this Blog


Recent Posts

#NoFrameworks at Agile Middle East 2020

The Art of Guesstimation: Why Shouldn’t We Estimate?

The Art of Guesstimation: Why Should We Estimate?

The Art of Guesstimation: Estimation on Software Projects

Planning: The Efficiency Zone

Categories: Fundamentals, Principle

One of the seven principles behind Disciplined Agile (DA) is Context Counts. Every person is unique, with their own set of skills, preferences for workstyle, career goals, and learning styles. Every team is unique not only because it is composed of unique people but also because it faces a unique situation. Your organization is also unique, even when there are other organizations that operate in the same marketplace that you do. For example, automobile manufacturers such as Ford, Audi, and Tesla all build the same category of product yet it isn’t much of a stretch to claim that they are very different companies. These observations – that people, teams, and organizations are all unique – leads us to a critical idea that your process and organization structure must be tailored for the situation that you currently face. In other words, context counts.


Figure 1 overviews the potential factors that you should consider regarding the context of the situation faced by your team.  We’ve organized them into two categories:

  1. Selection factors that drive your initial choices around your high-level way of working (WoW) and in particular your choice of initial lifecycle.
  2. Scaling factors that drive detailed decisions around your team’s WoW.

Of course it’s never this straightforward.  Selection factors will have an effect on your detailed WoW choices and scaling factors will also have an impact on your initial decisions.  Our point is that in general the selection factors have a bigger impact on the initial choices than do the scaling factors and similarly the scaling factors have a bigger impact on your detailed tailoring decisions than do the selection factors.

Figure 1. Potential context factors (click to enlarge).

Context factors are interdependent.  Figure 2 shows the major relationships between the context factors.  For example, you can see that:

  • As domain complexity rises the skills required to address that complexity also rise (harder problems require greater skill to solve).
  • As team member skills increase the size of the team required to address the problem it faces can shrink (a small team of skilled people can do the job of a larger team of lower-skilled people).
  • Your organizational culture and your team culture tend to affect one another, hopefully positively.
  • Your team culture will vary by organization distribution (your team will have a different culture than that of teams in a different division of your organization, or of teams in a different company).
  • The more organizationally distributed your team becomes the greater the chance that it will be geographically distributed as well.  For example, if you are outsourcing some of the work to another organization the people doing that work may be in another, lower-cost country.

Figure 2. Relationships between context factors (click to enlarge).


Let’s explore the scaling factors a bit. As we mentioned earlier, the scaling factors tend to drive your detailed decisions around your way of working (WoW). For example, a team of eight people working in a common team room on a very complex domain problem in a life-critical regulatory situation will organize themselves differently, and will choose to follow different practices, than a team of fifty people spread out across a corporate campus on a complex problem in a non-regulatory situation. Although these two teams could be working for the same company they could choose to work in very different ways.

Figure 3 depicts the scaling factors as a radar chart, sometimes called a spider chart. There are several interesting implications:

  • The further out you go on each spoke the greater the risk faced by a team. For example, it’s much riskier to outsource than it is to build your own internal team. A large team is a much riskier proposition than a small team. A life-critical regulatory situation is much riskier than a financial-critical situation, which in turn is riskier than facing no regulations at all.
  • Because teams in different situations will need to choose to work in a manner that is appropriate for the situation that they face, to help them tailor their approach effectively you need to give them choices.
  • Anyone interacting with multiple teams needs to be flexible enough to work with each of those teams appropriately. For example, you will govern that small, co-located, life-critical team differently than the medium-sized team spread across the campus. Similarly, an Enterprise Architect who is supporting both teams will collaborate appropriately with each.

Figure 3. Tactical scaling factors faced by teams.


The leading agile method Scrum provides solid guidance for delivering value in an agile manner but it is officially described by only a sixteen page guide. Disciplined Agile recognizes that enterprise complexities require far more guidance and thus provides a comprehensive reference framework for adapting your agile approach for your unique context in a straightforward manner.  Being able to adapt your approach for your context with a variety of choices (such as those we provide via goal diagrams) rather than standardizing on one method or framework is a very good thing.


This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.


Posted on: October 18, 2019 12:00 AM | Permalink

Comments (6)

Please login or join to subscribe to this item
Thanks Scott!

As the relative level of project complexity continues to increase, the influence and importance of context on delivery approaches also increases.

Beyond the guidance provided within the DA framework to understand options available, teams also need to understand the control objectives governing the work they are doing.

While context might change the "how", the "what" and "why" of these control objectives is unlikely to change until the underlying policies and regulatory standards change.

Exactly. Control objectives, sometimes motivated by regulatory compliance but also motivated by organizational decisions, will hopefully be enabling constraints or guardrails for your organization.

Thank you Scott. Your comments and the reference are important to me for three reasons.

1. As a practitioner
I'm encountering the need to remain fluid/agile in situations which are individual in nature. Each project/program requires a different hybrid method.

2. As a scholar
I need to ensure that the curriculum I'm teaching is aligned with the current/future trends of the profession

3. As a continuous learner & PMBOK 7 Review Team Member
I'm always looking for ways to stretch my mind for new ways of seeing the world.

It will be interesting to see how DA is absorbed by the PMI community and how it resonates with the PMBOK 7 changes currently under development.

Thanks for helping me learn today!



Good point about standards and governance. Who should be involved in those discussions, and how would one facilitate those? Just curious to have some discussion about this. This may be a "long game" strategy, but there might be some milestones along the way that we all can collectively work toward.

@John, we've got some fairly solid lean governance advice in DA that we certainly intend to flesh out in the near future. For now you might find the article at as well as some of the articles that it links to.

@Scott: Thank you. I'll check those out.

Please Login/Register to leave a comment.


"The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but rather, 'hmm.... that's funny...'"

- Isaac Asimov