Construction Iteration C10
This is the last Construction iteration before Transition, and everything is running smoothly within the team.
The focus of this iteration is to implement the high-priority stories that were identified during the previous iteration, and to harden the solution. During Iteration C9, Tara shifted her focus from helping the team with unit testing and automated acceptance testing to testing in BigBank's preproduction environment. Tara wanted access to this environment much earlier, but BigBank has limited resources for this sort of testing. By working with the preproduction test team, she found several system integration challenges that her team wasn't able to simulate up until now. Tara also invests time to thoroughly test the deployment scripts within the preproduction testing environment.
The team chooses to capture these defects as new work items, which are prioritized and put on the work item list. Each defect is assigned a size of zero, so that they are not counted toward the team's velocity. The decision was based on the recognition that, from the point of view of the stakeholders, the team should have found and addressed these problems before claiming that the original work was “done.” The team finds this a bit frustrating, but realizes that this is a learning experience for them. Carlos points out that having to spend an iteration or more hardening a solution is a common anti-pattern for teams new to agile.
Terry asks Tara to track the defects, by severity, in a simple spreadsheet. She tracks the severity of the issue, the date it was identified, a brief description, and the date it was resolved. This information is then summarized in a defect trend chart. Tara has done this sort of thing before using more sophisticated defect-tracking tools, but finds that the spreadsheet approach is sufficient for their needs right now. The defect trend chart is reviewed as part of the team coordination meeting each morning.
Day 3. During the morning, Terry reviews the deployment plan with Oliver and Samira. This plan describes how the team will work with Oliver's operations team to deploy the solution into production. The plan also indicates how the support team, managed by Samira, will be trained in time for the deployment. This training needs to occur over several days, because only a few help desk staff can be trained at any given time (the rest need to continue providing support to BigBank customers and staff members).
That afternoon, Terry and Patricia meet with Mindy, the vice president of marketing, and Mary Jane, who works for Mindy, to finalize the overall release schedule with her. The four have been meeting for 30 minutes on a weekly basis to coordinate the activities between the two teams. Mary Jane has been attending the iteration demos and has been actively working with Patricia to ensure that the marketing message reflects what the team is building.
Day 6. Patricia cancels her regular look-ahead modeling session, and instead spends the time crafting an email with Terry to communicate the release date to the stakeholder community. Although key stakeholders have known about the target release date for a while, the wider stakeholder community only knew that it was coming soon. This email indicates the intended release date, a description of what MAP does, an overview of why this is important to BigBank, and an indication of when to expect further communications. This email is submitted to Berhard, the business sponsor, and Victoria, the vice president of IT, for their review. The following day, they jointly send it out to their constituents.
Day 10. Patricia decides to run a two-hour demonstration of the overall solution to the stakeholders. Where previous demos have focused on the new functionality implemented during that iteration, this demo walks people through critical, end-to-end functionality of the entire solution. Patricia decides to invite everyone who has attended a demo in the past, and most are able to attend. The goal of this demo is to both communicate what the team has accomplished and to verify that they have, in fact, produced sufficient functionality to justify releasing the solution into production. During the demo, several stakeholders indicate that they would like more functionality than what is currently implemented, and Patricia asks them whether they can wait until a future release for that functionality. Two of the stakeholders are unhappy with that idea because they have heard this promise before from IT, only to find out that the next release is years away. Berhard states that the plan is to get just enough functionality into production now so as to get to market quickly and that they fully intend to start into the next release once this one is successfully running in production. Victoria confirms that she will be keeping the team together to work on the next release. The two stakeholders are relieved to hear this and not only acquiesce to waiting until the next iteration for their desired functionality, but also offer to be involved with any requirements elicitation sessions. The demo is a success, and everyone is excited to hear that the deployment into production is planned to occur two weeks from now.
The retrospective. The team is very excited to be this close to releasing their solution in production. Several people on the team believe that the Transition phase is going to go very smoothly, given the quality of the work that they've done.
Terry shares the updated release burnup chart with the team. Terry compliments the team for both hitting the desired date and for implementing all of the “must have” functionality identified for this release by the stakeholders. He says there is clearly more to do in the next iteration, and fully expects that the team will receive more requirements given the positive response in the demo earlier today.
Both Danny and Ashok point out how they're looking forward to a bit of a break, as they're a bit worn out from having to consistently deliver a consumable solution every two weeks. Carlos agrees, pointing out that it's common for agile teams to slowly burn themselves out if they don't pay attention to working at a sustainable pace throughout Construction. Carlos thinks that this is something the team should work toward during the next release, and the rest of the team agrees.
Tara brings up the problem she ran into with preproduction integration testing. In hindsight, she feels that it was left until too late in the life cycle, although she doesn't see how it could have been done earlier, given her lack of access to the appropriate environment. Carlos describes a Disciplined Agile practice called parallel independent testing, overviewed in Figure 10.1, where the development team tests to the best of its ability, but also provides their working build on a regular basis to an independent test team. This team takes their build, and the builds from other teams developing other solutions, and integrates them into a preproduction testing environment (sometimes called a “QA environment” in traditional organizations). The test team then performs the kind of testing that the development team isn't likely to be able to perform, and reports any potential issues back to the appropriate development team(s). Carlos believes that this will help the team to avoid the “hardening sprint” anti-pattern in future releases.
The Sufficient Functionality milestone review. Terry and Patricia meet with Padma, the PMO lead; Berhard; and Victoria to hold a milestone review. Terry wants to keep this as lightweight as possible. Terry summarizes the current status of the team, walking everyone through the burnup chart and the defect trend chart. Patricia and Berhard summarize the results of the demo earlier in the day for Padma, who hasn't been able to attend. After a brief discussion, everyone agrees that the Sufficient Functionality milestone has been passed successfully.