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.
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.
For complex agile projects, deploying (or transitioning) the release to a “live” environment for the users is seldom a trivial exercise. Most large enterprises have defined milestones, gates, and or reviews that need to be coordinated with many diverse stakeholder groups such as users, governance bodies (such as Project Management Offices), DevOps, and marketing before the application can be released. In DAD we therefore describe a distinct set of activities to prepare our stakeholders for the release and support of the new application. This could include activities such as user training, data conversion, documentation, hardware deployment, preparing customer support, database tuning, and last minute defect fixing. To recognize the clear difference from a typical Construction iteration, we describe iterations dedicated to deployment as “Transition” iterations. The illustration shows how we can inject iterations into our release schedule to deploy increments to the user community. In this example, after the fourth Construction iteration, we may have an additional set of features representing a minimally marketable release that is worthy of a Transition iteration to deliver the value to the users.
When we have an application that needs to be delivered over multiple releases, following the Transition phase we may start work on a new release by continuing the Construction phase. Since we would typically have an existing work item list (backlog) of outstanding requirements, we can simply pull more requirements off this stack and continue to build more functionality. In this way, it may not be necessary to have another Inception phase unless the vision has materially changed and needs to be revisited. Your organization may, however choose to run small Inception iterations at the beginning of each new release.
In this example, after the fourth Construction iteration, we may have an additional set of features representing a minimally marketable release that is worthy of a Transition iteration to deliver the value to the users.
Some people mistakenly interpret DAD as one deployment to the customer at the end of the project. If possible, we prefer to deploy frequently, in support of the agile alliance principle “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Our minor quibble with this principle is that what we deliver to the customer is a “solution”, which may not only include software, but also business process changes, training, or marketing activities, for example. Our experience is that large projects typically involve a lot of work beyond the software itself which can also benefit from agile collaborative practices.
Injecting Transition iterations to deploy increments to customers
While the illustration refers to each iteration delivering a “potentially shippable” increment, which is what the agile community typically calls it, we actually prefer to use the term “consumable” to indicate that it not only works, but it is also actually usable by the customer.
In our upcoming book we discuss patterns like these with considerations for what might make sense for your program or project in various circumstances.
Mainstream agile methods would suggest that we should have one product owner, being the “one” voice of the customer for matters related to release/iteration scope, priorities, and requirements clarification.
The reality that I see on most enterprise agile projects is that the product owner cannot possibly manage the work item list themselves. In fact, they are often not the best person to do this prioritization. I wish it were as easy as managing epics and user stories.
On my current project, we are in the process of taking ownership of a very large application built offshore. In DAD, we would describe this as the Transition phase of the product as we deploy the solution to our stakeholders. We will take over the build, deployment, support and enhancement going forward. This is a team of 20+ with responsibilities spanning development, infrastructure, and devops. Due to the complexity of the rollout we are doing it over a number of Transition iterations.
A simplistic view would suggest that the Program Manager is our product owner. At the end of the day he may have ultimate responsibility, but he is not collocated, and deals with the larger issues of the project, such as vendor management, governance, funding, resourcing, and other related issues. He delegates responsibility for the details to domain leads for the business, development, infrastructure and support.
My approach as the overall agile team lead is to treat the these traditional leads as product owners. They each have their own work items and priorities such as:
For these work items, who is responsible for designating priorities, assigning to iterations, and iteration planning? The last question is the easiest to answer. We let the team members doing the work do the task identification, estimating and assignment. The other questions are a bit more tricky. I don’t believe that any one person should determine the scope and prioriity of these diverse work items. Rather, as team lead, I would prefer to let the team leads of infrastructure, customer support and development (traditionally might be PMs) to self-organize and advise me on their priorities and in which iteration their work items should be completed. The summary of which is then reviewed with the Program Manager to assure alignment with the overall program’s goals.
Therefore what we are doing is co-managing the work item list with myself as facilitator.
This discussion shows some of the challenges in managing a DAD Transition iteration(s) using an agile approach. I understand that the idea of having shared product ownership is not consist with methods such as Scrum. However, in my world of large enterprise agile projects pragmatism trumps the agile “code”. As Barbossa says in Pirates of the Caribbean, “the code is more what you call guidelines than actual rules“.