Disciplined Agile delivery (DAD) is showing up in literature and Agile circles as an approach to use as a scaled...
Agile framework. Although some may label it a methodology, co-author of the framework and the books describing it, Mark Lines, explains it is not a prescriptive Agile methodology, but rather a process decision framework to provide guidance on which Agile techniques might be best to use in different situations, both large and small scale. Let's take a closer look at DAD to understand more how enterprises can use this Agile framework to help plan their Agile strategy.
The difference between DAD and SAFe
Dean Leffingwell's Scaled Agile Framework (SAFe) methodology has been growing in popularity as a large-scale approach to scaling Agile. Rather than a competitor to DAD, however, Lines describes SAFe as complementary to DAD. "I think SAFe is awesome," Lines said in open session where he was a student in Leffingwell's SAFe program consultant (SPC) training. Leffingwell and Lines, in fact, appeared together as well at the Brussels 2015 Agile Consortium, at which they both presented keynotes describing their respective frameworks and advice on how to best scale Agile.
Mark Lines recently co-authored with Scott Ambler the Introduction to Disciplined Agile Delivery: A Small Agile Team's Journey from Scrum to Continuous Delivery, to provide a supplement their earlier book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise. The shorter version provides a good summary for busy executives, suggested Lines, comparing the much skinnier compendium to the original 500-page handbook.
Having attended the SPC training in order to gain a deeper understanding of SAFe, Lines noted that the primary difference between DAD and SAFe is that SAFe provides a more prescriptive methodology, outlining roles, ceremonies and processes similar to Scrum, but at a larger scale, including program and portfolio layers on top of the team layer that is Scrum-based. DAD is considered a hybrid framework that adopts strategies and techniques from existing sources, including Scrum, Extreme Programming (XP), Kanban and Agile Modeling, and provides advice about which practices to use and how to apply them together.
A full delivery lifecycle with four versions
A full product lifecycle initiates with a concept and moves through to delivery, then on to operations and support, although often there are many iterations of the delivery lifecycle as new features are developed and deployed. The DAD lifecycle encompasses the delivery lifecycle which includes three phases: inception, construction and transition.
Although DAD includes a full scaling model and advice beyond the delivery lifecycle, the Agile framework supports four versions of the delivery lifecycle: an Agile/basic lifecycle, a lean/advanced lifecycle, a continuous delivery lifecycle and an exploratory lifecycle.
The Agile/basic DAD lifecycle is one that extends the Scrum model with ideas from XP and Rational Unified Process. The construction phase of this lifecycle is made up of time-boxed Scrum sprints and will be familiar to those who have Scrum experience. This is the most common lifecycle and it is recommended for the following situations:
- When the work is primarily enhancements or new features
- When the work can be identified, prioritized and estimated early in the project
- When teams are familiar with Scrum and XP, or when teams are new to Agile
The lean/advanced DAD lifecycle encourages use of lean principles such as minimizing work in process, maximizing flow, reducing bottlenecks and supporting a continuous work stream (rather than fixed, time-boxed iterations used in Scrum). Rather than a prescribed set of ceremonies (Daily Scrum, Sprint Planning, Retrospectives) held on certain cadences that are used in Scrum, lean suggests that these events are done as needed. DAD suggests that while the concepts behind lean and the Kanban system it uses are simple to learn, applying them properly to maximize throughput may be difficult to master. For this reason, DAD labels this lifecycle as advanced and suggests using it in these situations:
- When work can be broken down into small work units of approximately the same size
- When work is difficult to predict in advance, such as maintenance work
- When the team favors minimizing batch size and advance planning
The continuous delivery DAD lifecycle supports more frequent delivery than other lifecycles. In order for this type of lifecycle to be effective, there needs to be mature processes around continuous integration and deployment and an infrastructure supported by advanced DevOps practices. This type of lifecycle is best suited for these types of situations:
- When projects or applications can be delivered to stakeholders frequently
- When organizations have streamlined deployment practices and procedures
- When teams have mature DevOps practices in place, including continuous integration, continuous deployment and automated regression testing
The exploratory lifecycle minimizes upfront investments in favor of experimental applications that can be tested in the market and measured early and often during the project. Feedback from actual usage is used as the application is being developed. This exploratory lifecycle is useful in these types of situations:
- When the application addresses a new unexplored market
- When the stakeholders and delivery team can be flexible in adapting the application as it's being developed
- When you have a valid hypothesis/strategy to test with clear go/no-go criteria for when the test is over
Although DAD certainly can be used at the enterprise level to help those who wish to scale Agile, it can be used even for small mobile applications for teams that may want to make use of the exploratory lifecycle. DAD is not a methodology with a cookbook approach to software development, but rather a process framework that will help the team use the Agile processes and techniques that will provide them with the most value.
Agile meets mobile in little known Mobile-D
If continuous delivery is your goal, try this
How your know your Agile team is all grown up