Reduce Agile Project Risk with Light-Weight Milestones

1380920263rwpocDAD incorporates a number of milestones into its lifecycles to gauge the progress and health of your DAD projects/releases.

Why does DAD have milestones?

Governance is largely absent from mainstream agile methods and many believe that agile does not need milestones.   Scrum orders its backlog with highest value work at the top of the stack.  At the end of each sprint (iteration) a decision is intended to be made whether or not the next sprint of work in the backlog provides sufficient value to fund another sprint.  If not, the project stops.  While in principle this strategy makes sense, as a replacement for governance it is flawed for several reasons:

  • Not sufficient.  There is much more to effective governance than deciding when to cease the funding of a project.  How did it get started in the first place for instance?
  • Not realistic.  In reality most organizations tend to fund releases comprised of many iterations rather than make explicit funding decisions at the end of each sprint.
  • Effectively a milestone.  While Scrum claims to not have milestones, pausing to consider if sufficient functionality exists to deploy, and to determine a go-forward strategy is implicitly a milestone.  DAD makes them explicit with guidance for how to effectively apply them.

Why do we need agile governance?

Contrary to what many believe, the need for governance does not disappear for agile initiatives.  Sponsors and other stakeholders deserve and indeed demand periodic updates on the status of their investments.  They want answers to questions like:

  • What will I get from my investment and will it be worthwhile?
  • Is what is being delivered consistent with the initial funding request?
  • What is the status of the outstanding risks and what is being done to mitigate them?
  • Is the current release timeline consistent with the original projection?
  • When will we have sufficient functionality to go live?
  • Are all stakeholders prepared to receive the release?
  • When will the project be finished?

Claims that agile is “different” and does not need to provide these answers is one of the reasons that agile is sometimes seen as being undisciplined.  In fact these claims are often used by some as an excuse why agile won’t work for them.  Fortunately, since DAD has built in mechanisms to facilitate answering these questions many organizations are extending their agile implementations to incorporate DAD’s guidance.  Indeed DAD is very appealing to those looking for a way to govern projects while still remaining agile.

Milestone Reviews Should Be Kept Informal

Consistent with the strategy recommended in the DAD goal Fulfill the Team Mission milestone reviews should be done in a lightweight manner.  They typically coincide with the end of iterations or phases when when using the Agile/Basic lifecycle.  If you are unsure why DAD has phases you might find the blog posting on the rationale interesting.

Milestone Dates Should Be Communicated

It is a good practice to provide a calendar to stakeholders with milestone dates for each DAD project so that they can plan to attend iteration reviews that coincide with milestone reviews that they are interested in.  While milestone dates may change, it is very useful to have target milestones across a portfolio of projects visible as a roadmap to all stakeholders.

The DAD Milestones


Stakeholder Vision.  The goal of the Inception phase is to spend a short yet sufficient amount of time, typically one to four weeks in order gain stakeholder agreement that the initiative makes sense and to therefore continue into the Construction phase.  By addressing each of the DAD Inception goals the delivery team will capture traditional project information related to initial scope, technology, schedule, budget, risks, and other information albeit in as lightweight a fashion as possible.  This information is consolidated and presented to stakeholders as a Vision statement as described by the Develop Common Vision goal.  The format of the vision and formality of review with vary according to your situation.  A typical practice is to review a short set of slides with key stakeholders at the end of the Inception phase to ensure that everyone is on the same page with regard to the project intent and delivery approach.

Proven Architecture.  Early risk mitigation on a project is a part of any good project management discipline.  As the Prove Architecture Early process goal indicates, there are several strategies you may choose to adopt to do so.  The most effective of which is to build an end-to-end skeleton of working code that implements technically risky business requirements.  A key responsibility of DAD’s Architecture Owner role is to identify risks in the Inception phase.  It is expected that these risks will have been reduced or eliminated by implementing related functionality somewhere between one and three iterations into the Construction phase.  As a result of applying this approach early iteration reviews/demos often show the ability of the solution to support non-functional requirements in addition to, or instead of functional requirements.  For this reason it is important that architecture related stakeholders are given the opportunity to participate in these milestone reviews.

Project Viability.  An optional milestone to include in your release schedule is related to project viability.  At certain times during the project stakeholders may request a checkpoint to ensure that the project is progressing consistent with the vision agreed to at the end of Inception.  Scheduling these milestones ensures that stakeholders are aware of key dates wherein they should get together with the team to assess the project status and agree to changes if necessary.  These changes could include anything such as funding levels, team makeup, scope, risk assessment, or even potentially cancelling the project.  There could be several of these milestones.  If the stakeholders agree to changes the Vision may be updated at this time.  Scrum implicitly has this milestone at the end of each sprint.  DAD makes this an explicit choice and makes it’s frequency optional.

Sufficient Functionality.  While it is worthwhile pursuing a goal of a consumable solution (what Scrum calls a potentially shippable increment) at the end of each iteration, it is more common to require a number of iterations of Construction before the team has implemented enough functionality to deploy.  While this is sometimes referred to as a minimally viable product (MVP) this not technically accurate as classically an MVP is meant to test the viability of a product rather than an indication of minimal deployable functionality.  The more accurate term to compare to this milestone would be “minimum feature set”.  Regardless, many use the acronym to mean the latter.

DAD’s sufficient functionality milestone is reached at the end of the Construction phase when a sufficient functionality is available plus the cost of transitioning the release to stakeholders is justified.  As an example, while an increment of a consumable solution may be available every two week iteration, it may take two weeks to actually deploy it in a high compliance environment so the cost of transitioning the functionality may not be justified until a greater amount of functionality is completed.

Production Ready.  For non-trivial situations a formal Transition phase is often required to do final preparations as part of delivery of the solution to stakeholders.  Once sufficient functionality has been developed and tested, transition related activities such as data conversions, final acceptance testing, production and support related documentation normally need to be completed. Ideally much of the work has been done continuously during the Construction phase as part of completing each increment of functionality. At some point a decision needs to be made that the solution is ready for production.  Of course, if you’re following the continuous delivery lifecycle then the “Transition phase” has evolved into a “Transition activity” – regardless, someone still needs to ensure that the solution is consumable before you deploy the solution.

Delighted Stakeholders.  Governance bodies and other stakeholders obviously like to know when the initiative is officially over so that they can begin another release or direct funds elsewhere.  The initiative doesn’t end the day after deploying a solution to stakeholders.  There are often project closeout activities such as training, deployment tuning, support handoffs, post implementation reviews, or even warranty periods before the project is considered completed.  Lean has a term “delighted customers” which suggests that “satisfied” customers is setting the bar too low.  While DAD agrees, there are more stakeholders than just customers such as production support that we need to delight before we consider the project complete, thus the milestone name “delighted stakeholders”.

Give Milestones a Try

Agile promotes transparency and accountability to our stakeholders.  Take this to the next level by sharing and celebrating achievement of key milestones on your projects.

2 thoughts on “Reduce Agile Project Risk with Light-Weight Milestones

  1. Don O'Neill

    Agile Software Development (ASD) is endeavor centric with a nod to the customer space. Agile practitioners come with built-in resistance to requirements and planning. The result is rapid frequency of product releases, lower costs, and higher Technical Debt.

    Here are the successful Agile State Milestones to look for:

    Team selected
    Opportunity selected
    Opportunity value proposition established
    Way of working foundation established
    Stakeholders in agreement
    Work started
    Work performing (Initial Release)
    Stakeholder satisfied with deployment
    Work performing (Incremental Releases)
    Work under control
    Stakeholder satisfied in use
    Opportunity value proposition benefit accrued
    Work performing (Final Release)
    Way of working working well
    Work Closed


Leave a Reply

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