Disciplined Agile

DAD teams focus on producing repeatable results, such as delivering high-quality software which meets stakeholder needs in a timely and cost effective manner.  DAD teams do not strive to follow repeatable processes.  The observation is that because each DAD team finds themselves in a unique situation, to be most efficient they need to follow a unique process tailored to reflect that situation.  That “unique process” may be comprised of a relatively standard lifecycle and common practices such as architecture envisioning, database regression testing, non-solo development, and many others (granted, those practices may be tailored to reflect the situation too).  The point is that each team in your organization may follow a different process, albeit processes which share similar components defined by a common process framework, while achieving the results required of them. 

This may of course be heresy in some organizations.  The danger with “repeatable processes” is that they grow in size over the years to address all possible situations, and as a result address none of them very well.  Imagine a project team that is large and has regulatory compliance concerns.  This team will tailor its practices accordingly.  Now imagine a small team that doesn’t have to address regulatory concerns.  An organization focused on repeatable processes might have that team follow the same process that the previous team followed, even though some of the practices had been tailored to meet scaling factors that don’t apply.  In other words, the repeatable process included some aspects that were overkill for the second team, thereby impacting their ability to deliver in a timely manner or in a cost efficient manner.  In the vast majority of organizations, when given the choice, stakeholders prefer to spend the money wisely and have the solution delivered in a timely manner, not to have the team follow a consistently “repeatable process.”

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.

A few days ago I wrote about ranged burndown charts. Interestingly, if you track the ranges over time you end up with a chart such as the one below which corresponds to the estimating cone of uncertainty (depicted by the dashed lines).  It’s interesting to note that this example includes two common occurrences that you’ll see.  First, during iterations one and two the gross and net velocities were the same because no new functionality had been identified yet, resulting in an unranged estimate.  Second, iteration eight had a very small net velocity because the amount of new functionality was almost as much as the amount implemented, giving a huge estimation range due to the small net velocity.

Previously I discussed the difference between gross velocity and net velocity and now I’d like to show why they’re important.  A ranged burndown chart, an extension to normal burndown charts which apply both the gross and net velocity, is shown below.  Where a burndown chart uses the (gross) velocity to predict a potential end date, and by extension gives a feel for the potential project cost, a ranged burndown gives a potential range of end dates/costs.  Giving a ranged estimate is a known best practice in the IT community.

Because it’s possible that functionality can be dropped from a release part way through a project, perhaps because of a major shift in strategy or in an effort to hit a desired date, the net velocity will exceed the gross velocity that iteration.  In this case our advice is the use the change in requirements from the previous iteration to calculate the net velocity.

Note that this blog posting is excerpted from Chapter 10 of the book Disciplined Agile Delivery.

A few years ago, in Dr. Dobb’s Journal I wrote about estimating on agile development projects.  In that article I discussed burndown charts and how to extend them to show an estimation range.  The basic observation is that there is really two velocities exhibited by a team, the gross velocity and the net velocity.  The gross velocity which is the amount of work they complete in an iteration, which is what a regular burndown chart shows.  The net velocity is the change in the amount of work still to do, which is the amount of work completed in an iteration less the added amount of functionality that iteration.

So, as the diagram depicts if a team completes 20 points of work in an iteration but 5 extra points of work was added by the stakeholders, the gross velocity is 20 points whereas the net velocity is 15 points.  If there’s 230 points on the stack then the gross velocity implies that there are 12 iterations left and the net velocity 16 iterations, providing you with a ranged estimate.

Given that we now have two velocities to chart, not just one, this leads us to evolve burndown charts into what is called ranged burndown charts.