Disciplined Agile Delivery (DAD) Lifecycles

In previous blog postings I've defined Discipline Agile Delivery (DAD) but I haven't shared the lifecycle (although I have done so in a couple of white papers, most recently Scaling Agile: An Executive Guide) in this blog. Until now.

The DAD method combines strategies and practices from several software methods, including Scrum, Extreme Programming (XP), Agile Modeling, Agile Data, and the Open Unified Process (OpenUP).  One aspect of this "process idea reuse" is that the DAD extends the Scrum lifecycle to be a full-fledged delivery lifecycle.  Figure 1 overviews the Scrum lifecycle, which addresses the construction aspects of agile delivery quite well.  It depicts the product backlog which is a basic prioritized requirements stack; the concept of delivering incrementally in consistent time boxes (what Scrum calls sprints and other methods such as DAD call iterations); holding a daily coordination meeting; and demoing your work at the end of the sprint/iteration/timebox to get feedback from key stakeholders.  These are all great ideas, which is why the DAD method adopts and enhances them.

Figure 1: The Scrum lifecycle.  The focus is on the construction part of the lifecycle (click on the diagram for details).
 
Several years ago I wrote about the Agile lifecycle and the need to extend it beyond construction, and this thinking is reflected in the DAD lifecycle of Figure 2.  The DAD lifecycle extends the Scrum lifecycle in several important ways:

1. It includes explicit phases. Sacrilege!  Rhetoric aside, there are in fact serial aspects to agile software development.  Project teams go through an initiation effort - called "warm up" in Eclipse Way, Inception in Unified Process, Sprint 0 in Scrum, and Iteration 0 in other methods - at the beginning of a project.  Eventually the team will go through a release phase - called the "end game" in Eclipse Way
   
2. It includes project initiation.  During the Inception phase you perform basic project initiation activities such as requirements envisioning, architecture envisioning, initial release planning, getting funding for the project, and starting to build the team (among other tasks).  In the summer of 2009 I ran the 2009 Agile Project Initiation survey which revealed that the average agile team spent 4 week on initiation activities such as this, that 89% did some sort of up-front requirements work, and that 85% did some sort of up-front architecture work.
   
3. It includes release activities.  The DAD lifecycle also includes a Transition phase where you release your solution into production or the marketplace.  These activities typically include final testing and hardening of your solution, training end users, pilot/beta testing, finalizing documentation, running the solution in parallel with the system(s) being replaced, and so on.
   
4. It explicitly indicates production activities.  Many agile delivery teams are responsible for supporting the existing version(s) of their system which are currently running in production.  Because there are existing versions, the team will be getting enhancement requests and defect reports from their operations and support people.  Many of these requests can simply be treated as new requirements to be prioritized and put on the work item stack.  Some need to be addressed right away, particularly "severity 1" defects, which requires the delivery team to "stop the line", address the problem, release a patch or hot fix, then reintegrate the changes into the version they're currently working on.  My experience is that it's critical to include a production phase in your delivery lifecycle to make it explicit to the team that they need to take operations and support concerns into account.
   
5. It explicitly enhances the product backlog.  The product backlog has evolved into a work item list (or work item stack if you prefer).  Disciplined agile teams put more than just requirements on the stack, as you read above it is common to treat defect reports as you do requirements.
   
6. It explicitly includes critical milestone points.  An important aspect of the DAD method is that not only does it support self organization such as Scrum but it does so within an appropriate governance framework.  Disciplined agile teams recognize that they exist within a larger organization, that they should follow common development guidelines, that they should strive to leverage and build out the shared enterprise infrastructure, that they must report common metrics to senior management (hopefully automatically via the use of instrumented tooling such as we see on the Jazz platform).
   

One of the advantages of the DAD method over Scrum is that it doesn't require you to figure these common things out for yourself.

Figure 2. The Disciplined Agile Delivery (DAD) lifecycle (basic).  The focus is on the delivery portion of the system lifecycle, from starting a project to releasing the solution into production (click on the diagram for details).



Figure 4. An older version of the basic DAD lifecycle using Scrum terminology.  Use whatever terminology you're comfortable with, there is no "standard" (click on the diagram for details).