Introduction to Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable. As you can see in Figure 1, DAD is one aspect, and arguably the foundation, of the Disciplined Agile (DA) tool kit.

Figure 1. Overview of the Disciplined Agile (DA) tool kit.

DA Scope - Small

This article is organized into the following topics:

  1. Why DAD?
  2. People first: Roles in DAD
  3. A Hybrid Tool Kit
  4. Full Delivery Lifecycles
  5. Choice is Good: A Goal-Driven Approach
  6. DAD Teams are Enterprise Aware
  7. DAD Provides a Foundation to Scale Agile Tactically
  8. Pragmatism over Purism

Why Disciplined Agile Delivery (DAD)?

Many organizations start their agile journey by adopting Scrum because it describes a good strategy for leading agile software teams. However, Scrum is only part of what is required to deliver sophisticated solutions to your stakeholders. Invariably teams need to look to other methods to fill in the process gaps that Scrum purposely ignores. When looking at other methods there is considerable overlap and conflicting terminology that can be confusing to practitioners as well as outside stakeholders. Worse yet people don’t always know where to look for advice or even know what issues they need to consider.

To address these challenges DAD provides a more cohesive approach to agile solution delivery. It does this by:

  • Supporting a robust set of roles.
  • Being a hybrid. DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, SAFe®, LeSS, and several other methods.
  • Being open. Disciplined Agile (DA) is a non-proprietary, freely available tool kit, as you can see from this site.
  • Supporting several delivery lifecycles. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users. It also supports lean, continuous delivery, program (team of teams), and exploratory/Lean Startup versions of the lifecycle. Unlike most agile methods, the DA tool kit doesn’t prescribe a single lifecycle because it recognizes that Context Counts and Choice is Good.
  • Addressing all aspects of solution delivery. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP.
  • Providing choices, not prescriptions. Instead of the prescriptive approach seen in other agile methods, including Scrum, DAD takes a goal-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you.

People First: Roles in Disciplined Agile Delivery

DAD suggests a robust set of roles for agile solution delivery. These roles are overviewed in Figure 2.

Figure 2. The roles of DAD (click to enlarge).


A common question that we get is what is the difference between primary and secondary roles? Primary roles will occur on all DAD projects regardless of scale. Secondary roles, however, typically occur only at scale and sometimes only for a temporary period of time. Another common question that we do get is why are there so many roles? For example, Scrum has three roles – ScrumMaster, Product Owner, and Team Member – so why does DAD need ten? The primary issue is one of scope. Scrum mostly focuses on leadership and change management aspects during Construction and therefore has roles which reflect this. DAD on the other hand explicitly focuses on the entire delivery lifecycle and all aspects of solution delivery, including the technical aspects that Scrum leaves out. So, with a larger scope comes more roles. For example, because DAD encompasses agile architecture issues it includes an Architecture Owner role. Scrum doesn’t address architecture so doesn’t include such a role.

For more detail about these roles, see the article Roles on DAD Teams.

A Hybrid Tool Kit

In general, Disciplined Agile (DA) is a hybrid tool kit that builds upon the solid foundation of other methods and software process frameworks. DAD adopts practices and strategies from existing sources and provides advice for when and how to apply them together. In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DAD the mortar to fit the bricks together effectively.

Figure 3. Disciplined Agile Delivery is a hybrid

Diagram representing the Disciplined Agile hybrid toolkit

One of the great advantages of agile and lean software development is the wealth of practices, techniques, and strategies available to you. This is also one of its greatest challenges because without something like DAD it’s difficult to know what to choose and how to fit them together.

Full Delivery Lifecycles

The focus of DAD is on delivery, although how other aspects of the system lifecycle affect the delivery lifecycle are also addressed. As you can see in Figure 4 a full system/product lifecycle goes from the initial idea for the product, through delivery, to operations and support and often has many iterations of the delivery lifecycle. The following diagram a high-level view of the system lifecycle, indicating the three phases which are the focus of DAD project teams (DAD product teams typically don’t work in phases) as well as the phases that are the focus of Disciplined DevOps. The DAD portion is the (up to) three phases lifecycle where you incrementally build a consumable solution over time.

Figure 4. A high-level view of the delivery lifecycle (click to enlarge).

Lifecycle - DAD High Level System DevOps - Small

Obviously there’s more to it than what the high-level diagram shows. DAD, because it’s not prescriptive and strives to reflect reality as best it can, actually supports several versions of a delivery lifecycle. Six versions of the lifecycle are supported:

  1. The Agile lifecycle. This project lifecycle is based on Scrum but extended so as to provide a streamlined strategy from beginning to end. It is depicted in Figure 5 and described in the article DAD Lifecycle – Agile (Scrum Based).
  2. The Lean lifecycle. This project lifecycle is based on Kanban. It is depicted in Figure 6 and described in the article DAD Lifecycle – Lean.
  3. The Continuous Delivery: Agile lifecycle. This modern agile, stable-team lifecycle is based on Scrum. It is depicted in Figure 7 and described in the article DAD Lifecycle Continuous Delivery: Agile.
  4. The Continuous Delivery: Lean lifecycle. This modern agile, stable-team lifecycle is based on Kanban. It is depicted in Figure 8 and described in the article DAD Lifecycle Continuous Delivery: Lean.
  5. The Exploratory/Lean Startup lifecycle. This lifecycle is based on Lean Startup strategies. It is depicted in Figure 9 and described in the article DAD Lifecycle Exploratory (Lean Startup).
  6. Program lifecycle. This lifecycle is for a team of teams. It is depicted in Figure 10 and described in the article DAD Lifecycle – Program (Team of Teams).

Figure 5. DAD’s Agile lifecycle (click to expand).

Lifecycle - DAD Agile

Figure 6. DAD's Lean lifecycle (click to expand).

Lifecycle - DAD Lean
Figure 7. DAD’s Continuous Delivery: Agile lifecycle (click to expand).
Lifecycle - DAD Agile Continuous Delivery
Figure 8. DAD’s Continuous Delivery: Lean lifecycle (click to expand).
Lifecycle - DAD Lean Continuous Delivery
Figure 9. DAD’s Exploratory (Lean Startup) lifecycle
Lifecycle - DAD Exploratory
Figure 10. DAD’s Program (team of teams) lifecycle
Lifecycle - DAD Program

DAD teams will adopt a lifecycle that is most appropriate for their situation and then tailor it appropriately (remember the DA principle Context Counts). For more about this topic, including how to choose between each lifecycle, please read the article A Full Agile Delivery Lifecycle.

Choice is Good: Goal-Driven

DAD’s goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods. For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs. DAD then indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so. DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for. Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.

In the first DAD book we described goals in a non-visual manner using tables which explored the advantages and disadvantages of the techniques associated with an issue. In the second half of 2012 we began expanding on this approach and developed a way to represent goals in a visual manner using what we call a goals diagram (see Disciplined Agilists Take a Goal-Driven Approach for a detailed discussion of the notation).

Let’s work through some examples. Figure 11 depicts the goal diagram for Explore Scope, a goal that you should address at the beginning of a project during the Inception phase (remember, DAD promotes a full delivery lifecycle, not just a construction lifecycle). Where some agile methods will simply advise you to populate your product backlog with some initial user stories the goal diagram makes it clear that you might want to be a bit more sophisticated in your approach. What level of detail should you capture, if any (a light specification approach of writing up some index cards and a few whiteboard sketches is just one option you should consider)? What view types should you consider (user stories are one approach to usage modeling, but shouldn’t you consider other views to explore the data or the UI)? Default techniques, or perhaps more accurately suggested starting points, are shown in bold italics. Notice how we suggest that you likely want to default to capturing usage in some way, basic domain concepts (e.g. via a high-level conceptual diagram) in some way, and non-functional requirements in some way. There are different strategies you may want to consider for going about modeling. You should also start thinking about your approach to managing your work. In DAD we make it clear that agile teams do more than just implement new requirements, hence our recommendation to default to a work item stack over Scrum’s simplistic Product Backlog strategy. Finally the goal diagram makes it clear that when you’re exploring the initial scope of your effort that you should capture non-functional requirements – such as reliability, availability, and security requirements (among many) – in some manner.

Figure 11. The goal diagram for the Explore Scope process goal (click to enlarge).


There are several fundamental advantages to taking a goal driven approach to agile solution delivery, in that it:

  • Supports process tailoring by making process decisions explicit.
  • Enables effective scaling by guiding you through tailoring your strategy to reflect the realities of the scaling factors which you face.
  • Makes your process options very clear and thereby makes it easier to identify the appropriate strategy for the situation you find yourself in.
  • Takes the guesswork out of extending agile methods and thereby enables you to focus on your actual job which is to provide value to your stakeholders.
  • Makes it clear what risks you’re taking on and thus enables you to increase the likelihood of success.
  • Hints at an agile maturity model (this may not be a benefit).

DAD Teams are Enterprise Aware

Enterprise awareness is one of the principles of the Disciplined Agile (DA) tool kit. The observation is that DAD teams work within your organization’s enterprise ecosystem, as do all other teams. There are often existing systems currently in production and minimally your solution shouldn’t impact them. Better yet your solution will hopefully leverage existing functionality and data available in production. You will often have other teams working in parallel to your team, and you may wish to take advantage of a portion of what they’re doing and vice versa. Your organization may be working towards business or technical visions which your team should contribute to. A governance strategy exists which hopefully enhances what your team is doing.

Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you. Teams developing in isolation may choose to build something from scratch, or use different development tools, or create different data sources, when perfectly good ones that have been successfully installed, tested, configured, and fine-tuned already exist within the organization. Disciplined agile professionals will:

  • Work closely with enterprise professionals, such as enterprise architects and portfolio managers.
  • Adopt and follow enterprise guidance.
  • Leverage enterprise assets, including existing systems and data sources.
  • Enhance your organizational ecosystem via refactoring enterprise assets.
  • Adopt a DevOps Culture.
  • Share learnings with other teams.
  • Adopt appropriate governance strategies, such as the ones described here, including open and honest monitoring.

Enterprise awareness is important for several reasons:

  • You can reduce overall delivery time and cost by leveraging existing assets. In other words, DAD teams can spent less time reinventing the wheel and more time producing real value for their stakeholders.
  • By working closely with enterprise professionals DAD teams can get going in the right direction easily.
  • It increases the chance that your delivery team will help to optimize the organizational whole, and not just the ”solution part” that it is tasked to work on. As the lean software development movement aptly shows this increases team effectiveness by reducing time to market.

DAD Provides The Foundation for Scaling Agile Tactically

Figure 12 overviews the basic strategy for how DAD tactically scales agile software development . The fundamental observation was that many organizations were struggling with how to scale agile methods, in particular Scrum. We feel that the first step was to identify how to successfully develop a solution from end-to-end. Although mainstream agile methods clearly provide a lot of great strategies, there really isn’t any sort of glue beyond consultantware (e.g. hire me and I’ll show you how to do it) to put it all together. This is where the DA tool kit comes in, but that’s only a start as you also need to tailor your approach to reflect the context in which you find yourself.

Figure 12. Scaling agile tactically.

Scaling Agile

DAD provides a better foundation for tactically scaling agile in several ways:

  1. DAD promotes a risk-value lifecycle. The riskier work early in an endeavour in order to help eliminate some or all of the risk, thereby increasing chance of project success. Some people like to refer to this as an aspect of “failing fast” although we like to put it in terms of succeeding early or learning fast.
  2. DAD promotes self organization enhanced with effective governance. This is based on the observation that agile project teams work within the scope and constraints of a larger, organizational ecosystem. As a result DAD recommends that you adopt an effective governance strategy that guides and enables agile teams.
  3. DAD promotes the delivery of consumable solutions over just the construction of working software. In addition to producing software DAD teams also create supporting documentation, they need to upgrade and/or redeploy the hardware the software runs on, they potentially change the business process around the usage of the system, and may even affect changes to the organization structure of the people using the system.
  4. DAD promotes enterprise awareness over team awareness. Please see the earlier section on enterprise awareness.
  5. DAD is context-sensitive and goal-driven, not prescriptive. One process size does not fit all, and effective teams tailor their strategy to reflect the situation they find themselves in. One of the DA principles is that Choice is Good – DAD enables choice through it’s goal driven approach and through supporting multiple lifecycles.

Now let’s examine what it means to scale agile. When many people hear “scaling” they often think about large teams that may be geographically distributed in some way. This clearly happens, and people are clearly succeeding at applying agile in these sorts of situations (see some of the more evidence we’ve gathered that agile scales, as well as some of the older evidence), but there’s often more to scaling than this. Organizations are also applying agile in compliance situations, either regulatory compliance that is imposed upon them or self selected compliance (such as CMMI and ISO). They are also applying agile in a range of problem and solution complexities, and even when multiple organizations are involved (as in outsourcing). Figure 13 summarizes the potential scaling factors that you need to consider when tailoring your agile strategy.

Figure 13. Tactical scaling factors

SDCF Scaling Factors

Pragmatism over Purism

Disciplined Agile Delivery (DAD) provides a pragmatic approach from which to tailor a solution-delivery process for the context faced by a team. It also provides a foundation which to scale agile strategies tactically. DAD explicitly addresses the issues faced by enterprise agile teams that many agile methodologies prefer to gloss over. This includes how to successfully initiate agile teams in a streamlined manner, how architecture fits into the agile lifecycle, how to address documentation effectively, how to address quality issues in an enterprise environment, how agile analysis techniques are applied to address the myriad of stakeholder concerns, and many more.

More Information

Choose Your WoW!

The strategies/practices referenced in the goal diagram above are described, including the trade-offs involved and considerations for when (not) to apply them, in the book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working.

If you want to succeed at enterprise agile you need choices, not prescriptions.