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 *

1 × 2 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”



To explore how we can help you, please get in touch