Transition Phase Patterns

Several common strategies applied during the Transition phase seem to work well in practice, and several seem to work rather poorly in practice. The success of this phase is determined by your ability to understand and adopt the successful patterns appropriately and avoid the anti-patterns when you can. Let’s begin with some patterns for success:

• Short and sufficient. If the quality of the solution has been adequately validated during the Construction phase your transition effort can be short. Look-ahead planning in areas such as creating the implementation plan, communication, and training can expedite transition. In some extreme cases the transition phase can consist of running your full regression test suite one more time and if successful someone running the deployment scripts. This can be on the order of minutes or hours. Of course for the Transition phase to be truly considered successful you must wait for confirmation of stakeholder delight.

• Multiple iterations. For some situations it may make sense to deploy your solution over several iterations during the Transition phase. Examples could include the need to deploy the solution to a geographically dispersed set of users or where the number of users is large and a scaled rollout makes sense. The case study in the next chapter shows an example of where this might make sense.

• Proven deployment/installation. If you have a solid continuous deployment practice in place as described in Chapter 15, “A Typical Day of Construction,” your deployment to a production environment will go much more smoothly. It is often difficult to test your production deployments unless you have a production-like environment. Experience shows that if you do not test your deployment in such an environment there is a high degree of risk that the deployment will be troublesome.

• Choose your release patterns. In Chapter 10 we described various strategies for planning your releases and their cadences. Together, a set of planned releases constitutes a solution plan. The three phases of DAD have different goals depending on the stage of the project lifecycle. We want to make it clear that you have complete flexibility to introduce Inception iterations into your solution plan at logical points where there is a need to revisit or update the vision for the solution. Often this coincides with a funding gate. Similarly, since you want to deploy your system into the hands of your customer as frequently as possible you inject Transition iterations into the solution plan as often as makes sense. As you move more to an advanced DAD or lean approach your need for Transition iterations may actually disappear. The key point here is that you customize your mix of the three types of iterations in your solution plan based on your situation. Figure 18.4 shows examples of various patterns. The first pattern in this diagram is the Classic DAD Pattern, which appears in the DAD lifecycle diagram introduced in Chapter 1, “Disciplined Agile Delivery in a Nutshell.” The second example in this figure shows a long project of many Construction iterations with one big deployment at the end. This is not an approach that we recommend as it has many of the risks of delivery that we see with traditional approaches. The third example shows one Inception phase with multiple releases. This example also illustrates that a Transition phase could happen at any interval that makes sense for the stakeholders, resulting in varying lengths of Construction. The last example shows a lean approach whereby we deploy as frequently as possible as part of the Construction phase. In this example we do not have timeboxed iterations, but rather deliver the solution to customers in a continuous stream as work items are implemented.

  Figure 18.4. Examples of solution plans with multiple releases

  [View full size image]