Concept: Disciplined Agile Delivery Phases
This concept page defines the typical phases in a Disciplined Agile Delivery lifecycle.
Main Description

Inception phase

The purpose in this phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project.

There are four objectives of the Inception phase that clarify the scope, project objectives, and feasibility of the intended solution [KRO03]:

  1. Understand what to build. Determine an overall vision, including the scope of the system and its boundaries. Identify the stakeholders: who is interested in this system and what are their success criteria?

  2. Identify key system functionality. Decide which requirements are most critical.

  3. Determine at least one possible solution. Assess whether the vision is technically feasible. This may involve identifying a candidate high-level architecture or doing technical prototypes, or both.

  4. Understand the high-level estimate for cost, schedule, and risks associated with the project.

Key considerations

Projects may have one or more iterations in the Inception phase. These are among the reasons for multiple iterations:

  • Project is large, and it is hard to define its scope
  • Unprecedented system
  • Too many stakeholders with competing needs and complex relationships
  • Major technical risks demand the creation of a prototype or proof of concept

There are some commonly observed counterproductive patterns during the Inception phase. Some teams postpone providing estimates until they analyze the entire domain and have written a large amount of requirements documentation. This behavior often leads to "analysis paralysis." Another pattern is poor planning of Inception iterations. Avoid such patterns by planning iterations during Inception in a way that iterations are risk-driven, include early integration and testing, and produce a product increment that you can demonstrate to stakeholders. By default, have one (potentially short) iteration in Inception to avoid analysis paralysis.

Construction phase

The purpose in this phase is to complete the development of the system based upon the baselined architecture.

"Agile elaboration" is a potential reordering of some work items to push the technically risky ones to the top of the stack and then holding an explicit milestone check to ensure that you've proven the architecture during the early part of the Construction phase.

There are objectives for the Construction phase that help us to have cost-efficient development of a complete product -- an operational version of your system -- that can be deployed in the user community [KRO03]:

  1. Iteratively develop a complete product that is ready to transition to its user community. Describe remaining requirements, fill in design details, complete the implementation, and test the software. Release the first operational version (beta) of the system and determine whether users are ready for the application to be deployed.
  2. Minimize development costs and achieve some degree of parallelism. Optimize resources and leverage development parallelism between developers or teams of developers by, for example, assigning components that can be developed independently of one another.

Key considerations

Typically, the Construction phase has more iterations (two to four) than the other phases, depending on the types of projects:

  • Simple project: One iteration to build the product (to a beta release)
  • More substantial project: One iteration to expose a partial system and one to mature it to beta testing
  • Large project: Three or more iterations, depending upon the size of the project (number of requirements to implement for a beta release)

Transition phase

The purpose in this phase is to ensure that the software is ready for delivery to users.

There are objectives for the Transition phase that help you to fine-tune functionality, performance, and overall quality of the beta product from the end of the previous phase [KRO03]:

  1. Beta test to validate that user expectations are met. This typically requires some fine-tuning activities, such as bug-fixing and making enhancements for performance and usability.

  2. Achieve stakeholder concurrence that deployment is complete. This may involve various levels of tests for product acceptance, including formal and informal tests and beta tests.

  3. Improve future project performance through lessons learned. Document lessons learned and improve the process and tool environment for the project.

Key considerations

The Transition phase can include running old and new systems in parallel, migrating data, training users, and adjusting business processes.

The number of iterations in the Transition phase varies from one iteration for a simple system requiring primarily minor bug fixing, to many iterations for a complex system, involving addition of features and performing activities to make the business transition from using the old system to using the new system.

When the Transition phase objectives are met, the project can be closed. For some products, the end of the current project lifecycle may coincide with the beginning of the next lifecycle, leading to the next generation of the same product.