”Disciplined Agile Delivery (DAD) is a process decision framework that enables simplified process decisions around incremental and iterative solution delivery.”
WIKIPEDIA
To the Agile community, the DADDY of DAD is the Canadian software engineer Scott Ambler. In this interview, he tells us how DAD came to be and when we should use it. His baseline message: “DAD is ongoing work; we are constantly improving and evolving the framework!”
The story of the Disciplined Agile Delivery Framework, DAD, goes back 5–10 years when Scott Ambler was the chief methodologist for IT at IBM Rational. Having worked in dozens of organizations around the globe to help them understand and apply agile and lean strategies at scale, he and his colleagues noticed some recurring patterns.
It was clear that everyone was applying Lean & Agile techniques in their own, unique way, although there were similarities. Apparently, the organizations succeeding at Lean & Agile spent a lot of time and effort figuring it out. In other words: at the organization and industry level there was an incredible amount of waste going on resulting from the lack of a coherent, flexible process framework.
“As a matter of fact, very few people could describe what they were actually doing,” Scott Ambler remembers. “For example, when asked what process they were following we’d often hear ‘We’re doing Scrum’ or ‘We’re doing Kanban’ as if those were sufficient answers. When we looked at what they were actually doing they would have adopted some strategies from Scrum/Kanban, but also from Extreme Programming, Agile Modeling, Unified Process, and many other sources. Very often they would have reinvented ideas from these methods without even knowing it, spending a lot of time and money doing so.”
Timeline
The DAD 0.x framework was originally developed at IBM Rational. The focus at the time was on showing how Lean & Agile delivery works from beginning to end and to support the tactical scaling of agile/lean strategies to address larger teams, geographically distributed teams, regulatory compliance, outsourcing, and both technical and domain complexity. The IBM team worked closely with business partners, including Mark Lines, and was led by Scott Ambler.
2009–2012
DAD 0.x framework developed at IBM Rational
June 2012
Release of DAD 1.0; the first DAD book, Disciplined Agile Delivery.
August 2012
DAD site
October 2012
Intellectual property of DAD passed over to the Disciplined Agile Consortium
August 2015
Disciplined Agile (DA) 2.x released
A range of choices
So, what is DAD all about? Scott Ambler and his colleagues characterize it as a process decision framework. What they mean by this is that it provides guidance to IT delivery teams — and now also to IT executive teams — to help these identify the process-related decisions that need to be made. The DA Framework is oriented towards mid-to-large sized enterprises that need to have effective IT departments to support them.
“More importantly it provides a range of choices and the trade-offs associated with those choices,” says Scott Amble. “This means that people can better tailor their approach to address the context of the situation that they face. Because everyone is different – one process size does not fit all.”
The Building Blocks of DAD
Process goals.
Teams vary in size, they vary in the way that they are geographically or organizationally distributed, they vary by the domain and technical complexity that they face, and they vary by the compliancy issues that are relevant to them. Furthermore, teams are made up of unique individuals, each of whom has a set of unique skills and experiences. As a result every team works different at a detailed level. However, at a high level they must still address the same goals or capabilities in order to be successful. For example, at the start every team should do some initial requirements scoping, some initial architecture envisioning, some initial planning, and so on. How they approach these goals will vary depending on the situation they face. The DA framework describes 22 process goals that explicitly capture the process-related options available to teams. Each goal is visually described by a process goal diagram, effectively a stylized mind map. Every goal is described by several process factors, and each process factor by several potential practices or strategies that a team might consider to address that factor. These practices and strategies are taken from proven methods such as Scrum, XP, Agile Modeling, and many others.
Lifecycles
Because every team is in a different situation one lifecycle does not work for every team. The DA framework supports four full delivery lifecycles: A Scrum-based Basic/Agile lifecycle; A Kanban-based Lean lifecycle; A Lean Continuous Delivery lifecycle; and an Exploratory lifecycle based on Lean Startup. DA 2.0 also supports an IT lifecycle.
Process blades
A process blade describes a capability area within the DA framework. There are process blades for each of the four lifecycles as well as IT-level capabilities such as Enterprise Architecture, Operations, Portfolio Management, Data Management, IT Governance, and many others.
The one-size-doesn’t-fit all philosophy is crucial to DAD. Basically, organizations may use it as they please. IT is incredibly complex, and every organization suffers from different pain points in different aspects of IT. The DA framework shows how the various aspects of IT fit together, providing explicit guidance as to what issues/decisions you need to consider and a representative range of options from which to choose.
”DA doesn’t provide all potential options as that’s simply not possible — while you’ve been reading this article someone, somewhere in the world has come up with a new technique,” Scott Ambler says. “But it does get you thinking, and it does help you to recognize that you have choices and that each choice has advantages and disadvantages. There is no such thing as a best practice, only practices which should be applied in some contexts.”
In Scott Ambler’s opinion, there are two things that distinguish DAD from other frameworks:
”Firstly, the DA Framework provides options and guidance for making effective choices given the context of the situation that you face. Most other frameworks prescribe a single way of doing things, limiting their applicability in enterprise-class settings. Secondly, the scope of the DA Framework is critical. Too many frameworks focus on one aspect of IT and as a result are locally optimized (at best). The DA framework takes a system view of IT, enabling IT organizations to understand and potentially optimize their entire process.”
The major strengths of the DA framework
… for development teams
DAD shows how agile/lean techniques work from beginning to end. It describes how activities such as architecture, testing, analysis, programming, design, and so on fit together from beginning to end in a streamlined manner. In short it takes a lot of the mystery out of how agile software development actually works in practice.
… for IT executives
DAD shows how all aspects of IT work together. A huge challenge for IT executives is that the bodies of knowledge or expertise for IT capabilities are disconnected. For example, in the enterprise architecture space we have the Zachman and TOGAF frameworks. In the analysis space we have the IIBA’s BoK. In the data management space we have DAMA’s BoK. In the management space we have the PMI and Prince2 BoKs. In the operations space we have ITIL. And so on and so on and so on. These BoKs all have great ideas as well as mediocre ideas. They overlap with each other. They contradict each other. They promote different priorities. They are all biased towards their area of focus. Most importantly they don’t fit together well. Organizations need a bigger picture that provides coherent advice for how it all fits together. This is what DA 2.0 brings to the table.
Read more
The Disciplined Agile site where we actively share and evolve the DA material.
The Disciplined Agile Delivery discussion forum on LinkedIn.
The Disciplined Agile Consortium site that provides links to training, downloadable resources (whitepapers, posters), videos, and the Disciplined Agile certification program.
The Disciplined Agile Delivery book which describes the framework in detail.
The Introduction to Disciplined Agile Delivery book that overviews the framework and works through a case study in a large enterprise.
