Your assessment of your project's readiness for Construction has yielded results that say it is time to go ahead. What do you do next? You move on to managing the project iterations. Before you begin Construction, you need to think about some general things in terms of the iterative process. After you begin the Construction phase, detailed planning can begin for the next iteration. As each iteration draws to a conclusion, the detailed plan for the next iteration begins.
How Long Should Iterations Be?
Loosely explained, an iteration should be long enough to get something useful accomplished, but short enough to maintain a sense of urgency on the development team. The exact length depends in large part on the size of the development team. The larger the development team, the longer your iterations should be. Smaller teams can (and should!) have significantly shorter iterations. For example, an iteration length of about 6 weeks is appropriate for a team with six to ten developers. Small teams with two or three developers might have iterations 1 to 2 weeks long. For very large teams, with perhaps 20 to 30 developers or more, iterations 2 to 3 months long may be indicated. This figure could grow even larger for projects with multiple contractors and dozens of developers.
Determining the Content of Iterations
With some projects having thousands of requirements, how do you determine what requirements to assign to each iteration? I generally use five criteria to identify the contents of each iteration:
Construction Phase Iteration Planning
Toward the end of the Elaboration phase, it's appropriate and important to determine how many iterations will be needed to implement the project. This helps determine the total length needed for the Construction phase. You should also perform detailed planning for the first iteration in the Construction phase. What constitutes detailed planning? Let's take a closer look:
Detailed Planning of Iterations in the Construction Phase
What does detailed planning of an iteration involve? For each iteration, a plan should be prepared that takes into account the following points:
Other Aspects of Iterations
In addition to careful planning, consider the following points when conducting each iteration:
This process is illustrated in Figure 10-1. Note that progress does not begin at 0%, because some functionality should have been completed in earlier phases. The percentage complete graph indicates progress toward the Initial Operational Capability (IOC). Some additional development may still be needed in the Transition phase to complete the product.
Figure 10-1. Progress during the Construction phase
Assessing the Results of an Iteration
One of the keys to a successful application of the iterative development method is careful assessment of the results of each iteration. This assessment is an opportunity to evaluate progress against objectives and adjust the course of the next iteration accordingly. This is one of the advantages of iterative development. Adapting to lessons learned as you execute the process hones the team's direction and the likelihood of achieving a successful conclusion to the project. At the end of each iteration, consider the following questions:
Based on the answers to these questions, you can begin planning the next iteration. The most important points in the assessment involve whether the iteration's main purpose and goals were achieved, and whether any risks assigned to the iteration can be retired. If not, a more extensive evaluation, possibly involving project management, should be undertaken. Why were the assigned risks not resolved? How serious is this risk? If it is significantly serious, you need to determine whether the project should continue.
The remaining issues (such as whether any functionality had to be deferred) may simply be a matter of adjusting the amount of assigned functionality to a more realistic amount that can be accomplished by the team given the time allotted for the iteration.
Demonstrating the Results of an Iteration
During the Construction phase, the emphasis shifts from eliciting and defining requirements and identifying and mitigating risks toward implementing the functionality. During this time, interaction with the customer tends to reach a low point, with the exception of demonstrations of releases. The requirements have mostly been defined (perhaps at the 80% level), and the developers are busy implementing functionality. The testers are hard at work testing. Ironically, this occurs when the burn rate is at its highest. Accordingly, it is worthwhile to demonstrate selected iterations to your customer and end users. This helps maintain customer interest and involvement and, more importantly, allows them to give you feedback.
The notion of periodic demonstrations requiring customer involvement may be new to some customers. It is important to set expectations with the customer and to ask that they be available periodically for review of and comment on these releases. Depending on the customer, this may take some convincing. In fact, the process of demonstrating releases to the customer and eliciting their feedback may need to be executed a few times before it goes smoothly and the customer begins to recognize the value.
Although all iterations should produce an executable, demonstrable release, it may not make sense to demonstrate every iteration to the customer. If possible, demonstrations should be kept low-key and informal to minimize the preparation time. In some cases, preparation for formal demonstrations may take more time. You might need to prepare a demonstration script, sample data, and so on. Furthermore, unless the product is primarily a Web-based interface that could be accessed over the Internet, significant logistics might be involved, such as transporting servers to the location for the demonstration. Ideally, demonstrations should take place at the contracting location. This way, if a problem occurs during the demonstration, the entire development staff is available to help. Also, a demonstration conducted in the same environment in which it is developed minimizes setup and preparation time. Finally, although the iteration is executable, the functionality may be of little interest to the end users, particularly in the earlier iterations. For example, an earlier iteration may consist of implementing a complete thread of entering some value in a screen, processing it according to certain business rules, and storing the data in a database. Although the first time this is accomplished may be a significant technical achievement, it's hardly satisfying to see from a casual observer's perspective. In general, because these demonstrations should be conducted numerous times over a project's duration, the ceremony and preparation should be kept to a minimum. This may also involve some expectation-setting for the customer, who may not understand that these demonstrations are meant to be a work in progress and not necessarily the final, finished product.
Eventually, functionality is implemented that connects the presentation layer, or user interface, with significant implemented functionality that performs some useful function. Functionality involving successful implementation of business rules that can be observed through the user interface will be of particular interest to the users. If you cannot demonstrate every release, these are the releases you will want to focus on demonstrating to the customer.
Because your team has been intimately involved with developing the application, they know exactly what it does. However, at the demonstration, you need to tell the users exactly what will be demonstrated. Users should also be cautioned that the demonstration is a work in progress, so they may experience some bugs during the demo.
It's also wise to have a plan in place for collecting defect and change requests during the demonstration. I prefer to ask the users to make note of minor issues they observe and to voice any major issues they see. Depending on the personalities and interests of the people in attendance, you may hear a significant number of requests, or very few. I also like to set the users' expectations carefully regarding the implementation of any change requests. A brief (5-minute) explanation of the change request process may be indicated. Explain that any serious problems will receive immediate attention, but minor issues may be deferred so that the team can focus on implementing new functionality. If possible, before the demonstration, ask the project manager of the outsourcing organization to work with the people in attendance at the demonstration to set the final priorities on the change requests. If you make this arrangement before the meeting, you can then explain that the development team will work with the project manager of the outsourcing organization to set priorities. This takes some of the pressure off the team so that the users will communicate their issues regarding priorities to the project manager of the outsourcing organization.
When giving the demonstration, I always like to have at least three people available to perform the demonstration. The first person manipulates the keyboard and user interface. The second person speaks to the audience and explains what the user is doing as well as what the system is doing. Finally, I prefer to have a third person off to the side observing the audience closely and monitoring their reactions. You may want to have a fourth person in attendance at the demonstration solely for the purpose of documenting any voiced change requests. Let the customer have some time for exercising and trying out the release as well.
Regrouping After the Demonstration
It is quite possible that you will receive many change requests during the demonstration. This is not necessarily bad. On the contrary, it indicates serious interest from the attendees. I like to convene a meeting following a demonstration to discuss the results. The following attendees are suggested:
The purpose of this meeting is to discuss and prioritize the change requests received during the demonstration and to assess and evaluate the reaction of the attendees. As a start, the following are examples of discussions: