Disciplined Agile Delivery (DAD) Lifecycles

This content is syndicated from Agility@Scale: Strategies for Scaling Agile Software Development by ScottAmbler. To view the original post in full, click here.

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).
  " >image
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 3 depicts the advanced form of the DAD lifecycle.  This form of the lifecycle occurs on experienced teams that have originally adopted the basic, Scrum-based lifecycle of Figure 2 and evolved it over time to be leaner.  One of the implications of continuous improvement and continuous learning, key recommendations of the DAD process framework, is that your lifecycle will evolve.  Primary changes that you see between Figure 2 and Figure 3 are the adoption of a work item pool instead of a work item stack and the abandonment of iterations (the critical observation is that practices such as detailed planning, demos, retrospectives and so on do not need to be on the same cadence, hence iterations disappear).

Figure 3.  The Disciplined Agile Delivery (DAD) lifecycle (advanced).  Over time you will improve your strategy towards a leaner approach (click on the diagram for details).
" >image
One of the differences that you may have noticed between the Scrum lifecycle of Figure 1 and the DAD lifecycle of Figure 2 is different terminology is used.  For example, iteration is used instead of sprint.  Work item list is used instead of product backlog.  Although I believe that the terminology used in Figure 2 is more accurate, it really doesn't matter because it's easy to use Scrum terminology with DAD if you like.  You can see this clearly in Figure 4.  What is important is that you choose the terminology which you are most comfortable with, and be prepared to translate back and forth between terms as there are no standards and there never will be.  As an aside, you might find Translating Scrum Terminology to be of interest.

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).

DAD is still a process framework that you'll need to tailor to meet your unique needs.   More on this in future blog postings.
Also, you might find the  Disciplined Agile Delivery website to be of interest.

Leave a Reply

Your email address will not be published. Required fields are marked *

nine − five =