Iteration Planning, Execution, and Assessment

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:

• Requirements that are particularly risky get scheduled first. Although the biggest risks should hopefully have been driven out during the Elaboration phase, some implementation risks may remain. Some examples might be requirements that specify interfaces to legacy systems, requirements involving very complex algorithms, and requirements that the developers are not sure how to implement. The point is to embrace risk and face it head on. Don't save the hardest requirements for later. This just delays risk mitigation and can derail the project later. A project manager who consulted with me once complained that his project was in danger of cancellation if his team didn't show something working soon. He also said my recommendation to schedule risky items first could cause his project to be canceled. If this is the case, project cancellation is certainly an important risk to mitigate. I suggested that the project manager schedule some high-risk requirements early but mix in some key, easy-to-implement, easy-to-demonstrate requirements. Also, note that your assessment of "risky" requirements may change as time progresses. In each iteration, you learn more about the application, the environment, and various other areas. Your assessment of areas previously considered risky may change. Likewise, you may identify new risks that were previously unknown.

• Items that were planned for earlier iterations but were not completed should be reviewed for possible inclusion in the iteration.

• Components that represent functionality needed by subsequent code. These components must be identified and scheduled for coding and testing before they are needed for the rest of development.

• Requirements that represent functionality of particular importance to the users or customer should be scheduled in the earlier iterations. By scheduling these in the earlier iterations, you can demonstrate this important functionality to users earlier in the project. This helps you maintain the customer's interest in the project.

• High-priority defects discovered through demonstration of earlier iterations. This is an often-forgotten aspect of planning the scope of the Construction phase. Don't forget to give the developers some time to correct any defects found along the way. Hopefully, these will be few, but there may be enough to distract the developers from working on implementing new requirements.

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:

• What is the iteration's main purpose? Are you trying to mitigate a particular risk or complete a specific set of functionality? Having a high-level goal set for each iteration helps set the iteration's context. That way, if problems surface, you can make decisions in the context of the goal. If the iteration's deadline is approaching and you determine that you cannot accomplish everything, this high-level goal will help you decide which requirements you can drop while still achieving the iteration's main goal.

• What staff is available to develop the functionality? Each developer should be assigned to develop a portion of the functionality for the iteration. You need to work with the developers carefully to estimate each item assigned to the iteration. Ideally, each iteration should be a bit of a challenge to get completed on time but should definitely be achievable. Developers should experience a sense of accomplishment at the conclusion of the iteration. On the other hand, developers should be challenged enough that they do not finish too early. This is a delicate balancing act that is awkward at first, but you get better with practice.

Other Aspects of Iterations

In addition to careful planning, consider the following points when conducting each iteration:

• Each iteration is time-boxed. It is important to end each iteration on time. Sometimes, this means that some planned functionality may have to be deferred to subsequent iterations.

• Each iteration should produce a demonstrable, stable, executable release. Not all of these releases necessarily need to be demonstrated to the customer or end users, but this is important as a goal. This helps ensure and verify that all functionality was implemented and that all aspects of the process (including integration) were exercised.

• The code and artifacts for each iteration should be baselined in some sort of configuration management tool. The baseline should be easily produced on demand and should be isolated from ongoing development. This ensures that the results of the iteration can be inspected or demonstrated at any point in time. It also provides a stable code base on which testing can proceed.

• Testing of the code produced in an iteration, together with regression testing of code produced by previous iterations, should be completed by the end of each iteration. This is another key advantage of iterative development, because testing can begin very early, even in the Elaboration phase. In contrast, projects conducted with the Waterfall lifecycle process do not begin testing until very late in the project's lifecycle.

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:

• Review the main purpose and goals you identified before the iteration began. Were the goals achieved?

• Of the functionality assigned to this iteration, was any not completed?

• Were any risks to be investigated or mitigated during the iteration successfully overcome?

• Were any new risks or problems identified?

• Have you received any feedback from prior iterations from the customer that might suggest a change in direction?

• Have any new events occurred that might change the project's focus, such as the final due date or project funding? Have there been any changes in the customer's staffing or changes among the key users? If so, this might suggest changes in the users' wants and needs.

• Are there any issues in project staffing (such as a team member who is having difficulty completing functionality) or problems with the development environment?

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 project manager of the outsourcing organization

• The project manager of the contracting organization

• The lead user representative and internal project champion

• The technical lead of the contracting organization

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:

• What is the meeting's general consensus? Was the demonstration well received?

• If few or no change requests were received, why? Is it because the demonstrated functionality was exactly what the attendees expected? Could it be because the wrong people attended the meeting?

• If many change requests were received, why? Does this mean the demonstrated functionality was not what the attendees expected? Or is it simply a reflection of intense interest on the part of the attendees? Sometimes, users are so enthusiastic at a demonstration that they get carried away with minor change requests. This is a key evaluation parameter. You need to determine if any adjustments in the project's direction are needed or whether to continue in the same direction.