Transition
The focus of the Transition phase in Disciplined Agile Delivery is for a team to release their consumable solution into production successfully. This should be done in as lightweight a manner as possible. In fact, when a team is allowed to stay together, this “phase” tends to evolve into an activity through automation—something we'll see in the next chapter. As you can see, there are two process goals to address during Transition: the first to ensure that you're ready to deploy, and the second to actually deploy.
Ensuring that the solution is ready to deploy. To do this, the team needs to:
•Perform final testing and fixing. The final testing effort is very short, at least by BigBank standards, due to the number of automated regression tests and the hardening work during Iteration C10. Tara, Danny, and Dick spend a lot of time testing in the preproduction environment, writing up a brief defect report for each potential issue they found. The issues are prioritized by Patricia as severity one through four. Any severity one defects have to be fixed, severity two defects should be fixed, and threes and fours are left to a future release if need be. These defects are tracked in Tara's spreadsheet and the defect trend chart presented in the daily coordination meeting. It is common for Berhard and someone from Oliver's operations team to attend these coordination meetings.
•Support training of the help desk staff. Training is delivered to Samira's help desk team over a period of six days. Each training session took three hours to run, and was presented to a portion of the help desk staff each time. During each training session, either Ashok or Terry attends so as to answer any specific questions participants have about MAP.
•Finalize the deliverable documentation. This proves to be a very minor effort due to the continuous documentation work performed by the team during Construction. Final reviews of the documentation are held with key stakeholders of each document, and appropriate changes are made. For the most part, the reviewers find minor consistency problems with the documents, a common problem when documentation is evolved over time (people sometimes forget to go back and update previously written material).
•Support development of end-user training videos. The team is asked to help record seven two-minute training videos to be delivered as part of the overall solution. There is a brief overview of MAP, and there are six “how to” instructional videos. Debbie, Patricia, and Barbara work together with Mary Jane to finalize the scripts. Mary Jane hires a professional actor to record the videos.
•Validate the deployment scripts. Ashok and Tara work with Oswald, an operations engineer from Oliver's team, to review and validate the deployment scripts. Tara has already thoroughly tested these scripts in the preproduction environment; in fact, she has been using them for several weeks successfully. The scripts are written so that environment information, such as the names and IP addresses of machines, is determined dynamically at run time. As a result, the review just needs to focus on the contents of the configuration file describing the production environment.
Deploying the solution. Oswald runs the deployment scripts to release the solution into production. Due to regulatory compliance needs, BigBank has a strict policy of separating the development roles and release management roles. Someone who is actively involved with development is not allowed to deploy into production—someone from Oliver's team must perform this work. This is why Oswald, and not a team member, is responsible for running the deployment scripts. It takes less than 10 minutes to do so.
Preparing for the next release. During some free time, the team meets for one hour to do release planning for the next release. This release took about six calendar months—three weeks for Inception, 20 for Construction, and two for Transition—but at the prodding of Berhard, the team decides that the next release should take only four months. Patricia holds some requirements-envisioning sessions to identify requirements for the following release. This comprises a two-hour requirements-envisioning session with several key stakeholders, followed the next day by a one-hour prioritization meeting. This effectively gives the team a head start on Inception for the second release. Unfortunately, the team doesn't have time to size the new requirements, so that work moves into a two-week “Inception phase” for release 2.
When you keep a team together so that they can work on the next release, you find that the Inception effort becomes much less (the team is already together, the environments are set up, the architecture is in place, funding is usually in place, and so on). In fact, most of the remaining Inception effort focuses on scoping and planning the next release, and that's typically a short effort. In this team's case, they are able to complete it in their spare time during Transition.
Although the average agile team spends about a month performing Transition activities, the mortgage application portal (MAP) team is able to do it in only two weeks. They are able to do this because of their focus on quality and testing issues throughout Construction, their adoption of the continuous documentation practice, their practice of automatically deploying their working build into demo and test environments (a big step toward continuous deployment), and working closely with operations and support staff to plan their deployment. Furthermore, the team feels that it could have been one week, had it not been for the need to spread out the training of the support staff. In the next release, they hope Transition will be faster, as the MAP will not be a new system and they will require less training.