This post is a follow-up to Comparing DAD to the Rational Unified Process (RUP) – Part 1. In that post I described in some detail why Disciplined Agile Delivery (DAD) is not “Agile RUP”. DAD is quite different in both approach and content. There are however some very good principles that the Unified Process (UP) incorporates that are not part of mainstream agile methods. This post describes what parts of the UP made it into the DA toolkit.
DAD suggests a full delivery lifecycle approach similar to RUP. DAD recognizes that despite some agile rhetoric projects do indeed go through specific phases. RUP explicitly has four phases for Inception, Elaboration, Construction, and Transition. For reasons that I described in the last post, DAD does not include an explicit Elaboration phase. However the milestone for Elaboration is still in DAD which I will describe shortly. As the DAD basic lifecycle diagram shows, DAD has three of the four RUP phases.
- The Inception phase. An important aspect of DAD is its explicit inclusion of an Inception phase where project initiation activities occur. As Scott Ambler says in one of his posts “Although phase tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project. While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than the general perception (the 2009 Agile Project Initiation survey found the average agile team spends 3.9 weeks in Inception)”. So in DAD’s Inception phase (usually one iteration) we do some very lightweight visioning activities to properly frame the project. The milestone for this phase is to obtain “Stakeholder consensus” on how to proceed. In the book we describe various strategies to get through the Inception phase as quickly as possible, what needs to be done, and how to get stakeholders consensus.
- The Construction phase. This phase can be viewed as a set of iterations (Sprints in Scrum parlance) to build increments of the solution. Within each iteration the team applies a hybrid of practices from Scrum, XP, Agile modeling, Agile data, and other methods to deliver the solution. DAD recommends a risk-value approach of prioritizing work in the early iterations which draws from the RUP principle of mitigating risk as early as possible in the project by proving the architecture with a working solution. We therefore balance delivering high-value work with delivering work related to mitigating these architectural risks. Ideally we deliver stories/features in the early iteration that deliver functionality related to both high business value and risk mitigation (hence DAD’s “risk-value” lifecycle). It is worthwhile to have a checkpoint at the end of the early iterations to verify that indeed our technical risks have been addressed. DAD has an explicit milestone for this called “Proven architecture”. This is similar to the RUP Elaboration milestone without risking the confusion that the Elaboration phase often caused for RUP implementations. All agile methods seek to deliver value into the hands of the stakeholders as quickly as possible. In many if not most large enterprises it is difficult to actually deliver new increments of the solution at the end of each iteration. DAD therefore recognizes this reality and assumes that in most cases there will be a number of iterations of Construction before the solution is actually deployed to the customer. As we make clear in the book, although this is the classic DAD pattern, you should strive to be able to release your solution on a much more frequent basis in the spirit of achieving the goal of “continuous delivery”. The milestone for the end of Construction is that we have “Sufficient functionality” to deploy to the stakeholders. This is the same milestone as the RUP’s Construction milestone. During the Construction phase it may make sense to periodically review the progress of the project against the vision agreed to in Inception and potentially adjust course. These optional milestones in DAD are referred to as “Project viability”.
- The Transition phase. DAD recognizes that for sophisticated enterprise agile projects often deploying the solution to the stakeholders is not a trivial exercise. To account for this reality DAD incorporates the RUP Transition phase which is usually one short iteration. As DAD teams, as well as the enterprise overall streamline their deployment processes this phase should become shorter and ideally disappear over time as continuous deployment becomes possible. RUP’s Transition milestone is achieved when the customer is satisfied and self-sufficient. DAD changes this to “Delighted stakeholders”. This is similar to lean’s delighted customers but we recognize that in an enterprise there are more stakeholders to delight than just customers, such as production support for instance. One aspect of RUP’s Transition phase is that it is not clear on when during the phase deployments actually take place. Clearly stakeholders aren’t delighted and satisfied the day the solution goes “live”. There is usually a period of stabilization, tuning, training etc. before the stakeholders are completely happy. So DAD has a mid-Transition milestone called “Production ready”. Some people formalize this as a “go/no go” decision.
So in summary, DAD frames an agile project within the context of an end-to-end risk-value lifecycle with specific milestones to ensure that the project is progressing appropriately. These checkpoints give specific opportunities to change course, adapt, and progress into the next phases of the project. While the lifecycle is similar to that of RUP, as described in Part 1 of this post it is important to realize that the actual work performed within the iterations is quite different and far more agile than a typical RUP project.
At Scott Ambler + Associates we are getting a lot of inquiries from companies seeking help to move from RUP to the more agile yet disciplined approach that DAD provides.