Construction Iteration C3
Construction Iteration C3 begins on an uptick. The team is excited because the second iteration was successful and the general consensus is that it will be the same for this iteration. Terry leads the team through iteration planning, which takes a bit less than three hours. This is much faster than what has happened in the past. This is due, in part, from the team's greater experience with iteration planning, but mostly due to the look-ahead modeling efforts led by Patricia and Ashok.
The daily coordination meetings are running much better. Everyone is showing up on time and, for the most part, staying focused on coordinating their day instead of trying to solve problems in the meeting. However, Danny is still struggling to participate effectively in the meetings.
Day 2. During the team coordination meeting, both Danny and Debbie ask Tara if she has some time to pair with them separately to help them test their work. To do this, Tara sits right beside a developer and works with them to write both production code and the unit tests to validate that new code. After a bit of time to get used to it, Tara and the developer swap the keyboard regularly, talk through the logic of how to test something, and most importantly, learn new skills and ways of thinking from each other. Throughout the rest of the iteration, Tara spends about two-thirds of her time pairing with either Danny, Debbie, Ashok, or Terry in this manner. The other third of her time is spent on other forms of testing, including functional, integration, and stress testing. During the iteration planning session the day before, Tara indicated to the team that she had intended to spend most of her time pairing with others to help them test. This is in line with the test strategy that the team had agreed to earlier during Inception.
Day 6. Early in the afternoon, Patricia leads a look-ahead modeling session with several stakeholders to explore upcoming requirements. During this session, the stakeholders not only describe how the stories for the upcoming iteration should work, they also identify several new stories and drop a few of the low-priority requirements. These changes result in what looks to be a 20% increase in scope.
Patricia goes to Carlos in a bit of a panic, asking for help to deal with this “scope creep.” Having worked with IT teams before, albeit ones following a traditional approach, Patricia is worried that this increase in scope will put the team at risk. Carlos points out that a big spike in new requirements early in Construction is quite common on agile teams. It is the natural result of greater stakeholder participation—when you produce a consumable solution on a regular basis, show it to people, and ask for their feedback, you typically get it. It's healthy for the requirements to evolve as it increases the chance that the team will build something the stakeholders actually want as opposed to something built to specifications.
Day 7. During the daily coordination meeting, Patricia informs the team about the new requirements. Terry suggests that the team spends some time today to have Patricia walk through the new requirements so that the team can identify the potential impact. The team decides to do this immediately following lunch. Patricia begins the session describing the changes and the reasons behind them. After a bit of discussion around how to implement the new stories, the team is convinced that the new requirements will not impact their architecture strategy at all. They decide that this is due to the initial modeling they did during the Inception phase.
Terry leads the team through sizing the new requirements using the relative-mass sizing technique, taking about 30 minutes to do so. The total time for the impact assessment meeting was a bit more than 1.5 hours. After this, everyone on the team, except for Terry and Patricia, goes back to work. Terry and Patricia work together to update the release burnup chart, which now shows that the team is likely to need 12 Construction iterations in total. Because Berhard, the sponsor, has made it clear that the schedule is firm, Patricia realizes that she needs to call a meeting to rethink which requirements are “must haves” for this release and which can wait for a future release.
Day 8. During the coordination meeting, Terry and Danny discover that they both worked on the same functionality the previous morning. Although this was a bit frustrating for both of them, for Danny it was a valuable lesson in why everyone needs to actively participate in team coordination meetings.
Day 9. Patricia facilitates a one-hour meeting with Berhard and the stakeholders who were involved with the modeling session on day 6. During the meeting, she negotiates with them to allocate some of the lower priority requirements to be implemented in the next release. Fortunately, management has learned that treating this initiative as a series of releases, similar to a typical product management strategy, is a better approach than funding one project at a time. Knowing that there will be more funding allocated to a future release makes these scope negotiations much easier. About 70% of the requirements, including most of the new ones, are marked as “must haves” for the first release. All others are marked as “nice to have” that ideally will be implemented in the first release, although if they get pushed to a future release, the stakeholders will accept it. This categorization will enable the team to make their delivery date. Terry also attends the meeting to represent the team, but for the most part spends his time listening to the discussion.
Day 10. The team finds that it has much less hardening to perform during this iteration. This is due to doing more testing earlier in the life cycle. The demo goes very well. The stakeholders like what they're seeing and feel very optimistic about the progress being made. This sense of optimism is new to them, as their previous experiences working with IT have always been problematic. Due to the degree of their active participation with the team and through regular demonstrations, they realize that they are less likely to encounter nasty surprises late in the life cycle, which has been typical in the past.
Terry shares the updated release burnup chart with the team, shown in Figure 8.1. The chart now shows two requirement lines, one showing the number of “must have” points and the other showing the grand total of points. Patricia describes to the team what happened during the prioritization session with the stakeholders the day before. Terry then explains that, with the new version of the burnup chart, the point where their burnup line meets the must-have line is the earliest time that they can decide to release/transition their work into production. At this point, they will be completely done all of the requested work. This is known as the Sufficient Functionality milestone.
The retrospective. The team begins with a review of how they're doing with implementing the process improvements from previous iterations. Their approach to testing has clearly improved, although they have much more work to do. The iteration planning session went smoother this time, and everyone hopes it will be even better in the next iteration. Team coordination meetings are also going better each day as well, although they sometimes last up to 20 minutes, so there is still room for improvement.
Ashok says that he's a bit worried about the level of documentation that the team is producing. A few days earlier, Oliver, the manager of the operations team, asked Ashok whether the team had started to work on the system overview documentation that's required as part of the overall solution. Ashok said that the team had been capturing notes and photos of diagrams in their team wiki, but had not yet started developing any form of “deliverable documentation.” Although they're still early in Construction, Ashok feels that they really should be evolving the supporting documentation along with the software that they're building. This reflects DAD's philosophy of developing consumable solutions, not just working software. Carlos suggests that the team adopts the practice of continuous documentation, where they write the supporting documentation in parallel to writing the code. He suggests that this can be done in the wiki, and that all the team needs to do is invest a bit more effort to capture sufficient information there. Carlos also offers to pair with anyone needing help.
On a related note, Dick reveals that he's been maintaining a detailed data model so far. Danny jokes that this was a well-known secret, because everyone on the team knew this was going on. Dick admits that he thinks he's wasted a lot of time maintaining this detailed model. The requirement spike earlier in the week caused him to do a couple of hours of rework on his model, some of which was removing data structures that were no longer needed due to dropped functionality. He's come to realize that evolving the database schema via database refactoring techniques is very safe and straightforward, removing the need for up-front detailed data modeling. Instead, he's going to perform database design work on a just-in-time (JIT) basis from now on.