Governing the DAD Lifecycle with Milestones for Successful Enterprise Agility

By Doug Rose

While most enterprise agility methods deplore any hint of management planning and oversight and encourage teams to self-govern, DAD introduces a light amount of governance in the form of milestones that serve more like checkpoints to ensure that everyone involved stays on track. Milestones are placed at various points along the delivery lifecycle. DAD uses the following milestones:

  • Stakeholder vision: At the end of the inception phase, you should have a vision statement that describes the agreed upon stakeholder vision for the product.
  • Proven architecture: Having a proven architecture early in the construction phase helps to mitigate risk. The team’s architecture owner is encouraged to identify risks in the inception phase and make sure these risks have been reduced or eliminated by implementing related functionality between one and three iterations into the construction phase.
  • Project viability: Project viability milestones give stakeholders an opportunity to check progress during the construction phase, ensure that the project’s progression aligns with the stakeholder vision agreed to in the inception phase, and discuss possible changes with the agile teams. Project viability milestones are optional.
  • Sufficient functionality: Sufficient functionality means that the product has the minimum feature set to satisfy the stakeholder needs. This milestone comes at the end of the construction phase. It is similar to what Scrum refers to as a “potentially shippable product increment,” but is more like what some agile teams refer to as a minimum viable product (MVP).

    This milestone is reached only when functionality is sufficient to meet the cost of transitioning the release to stakeholders. So, while a product may be viable after a two-week iteration, it may not have sufficient functionality to justify the cost of deploying it in a high-compliance environment.

  • Production ready: During the construction phase, other activities must be conducted and completed as part of the final preparation to deliver the solution to stakeholders, such as final acceptance testing, data conversions, and documentation. Near the end of the transition phase, everything required for the solution to be delivered to stakeholders must come together to make the solution production-ready.
  • Delighted stakeholders: The delivery cycle extends beyond the transition phase before a project can be considered completed and the team can begin on another release. These post-transition phase activities include training, deployment tuning, support, reviews, and warranty periods. The project isn’t considered complete until stakeholders feel delighted.