Construction Phase Planning: The Project Heartbeat

One reason to develop in iterations, especially short ones where you obtain rapid feedback from your stakeholders, is to get into a rhythm of delivering working software. This characteristic is emphasized by many of the agile evangelists. RUP has implicitly endorsed it since its inception (pun intended). Some people talk about the rhythm as the heartbeat of the project. Every iteration, the project team's heart beats and pushes the lifeblood, working software through the system. The cycle removes some of the bad blood (defects) and adds nutrients (features and fixes).

When you develop iteratively, you create detailed plans only for the next iteration. Because of the small size of the PSP Tools project, we found that planning became a transparent part of the process. We should explain what we mean by this term .

Discovering Our Own Rhythm

Because we were working on PSP Tools in our "spare" time, we were unable to time-box iterations and maintain reasonable expectations of what we could accomplish in a specific time period. ^[6] The problem we faced was that there were occasions when we would allocate a period of time, two weeks for example, during which we hoped to complete an iteration. But due to pressures from our real jobs and real lives, little or nothing would get done. We could have followed a true iterative process and developed a plan for what we expected to do, assess our progress, decide that we missed most of the objectives, and re-plan for the next two or three weeks. This would take time and, frankly, the effect on the team of missing the deliverables would take its toll on our morale .

^[6] Many people, including us, have learned that iterations are usually fixed in time. While this is generally true, you can use some other measure, such as the functionality you are adding, and still follow an iterative development process. We recommend that you consider using other measures only when there is no way to time-box the iteration.

Many of our meetings started with "Are we stalled again?" Feelings of guilt ensued; we beat our chests, put on hair shirts, embarked upon the next "iteration," and sunk deeper into the depths of despair.

We needed a change of attitude. We needed to feel good about what we were doing while recognizing the constraints on our time. Every one of the team members had a rich life outside of work. Our workdays were full. Sometimes we had little or no time to contribute to our project. Often, as soon as one person became available to contribute, the person on whom they depended entered into a crunch period. This specific problem might not occur on most of your projects. But often a team becomes demoralized for reasons that really are beyond any team member's control.

When something is not working, you need to try another approach rather than continue to do what doesn't work and hope for the best. During the Construction phase we found that by using the Engineering Backlog and Defects tools in Groove, we were able to make progress regularly, if not on a schedule, and the software took shape rapidly .

Chris and Gary talked several times a week, either face-to-face, on the phone, or through an online chat tool. Whenever one had a question, he was usually able to contact the other immediately. This communication and feedback allowed them to coordinate their work and deliver working features to the rest of the team. When they felt that PSP Tools had enough new features to make it worthwhile to run acceptance tests and get customer feedback, they built the PSPTools.jar file and copied it to the Drops For Testing folder. Then Jas and Liz could test when they had time. Russell could monitor the progress and provide feedback when he was available. This asynchronous style of working propelled us into a richly productive period.

Communicating by Release Notes

To facilitate this process, we needed to produce one document with every drop: a short set of release notes. If the release contained bug fixes only, we pointed to the Defects tool rather than describe the fixes in detail. If we added new features, we included enough information for Jas or Liz to begin testing them, perhaps by referring to a specific use case or scenario.

We had to make a small change to our Defects list. We originally forgot to number each defect, making it cumbersome to refer to a specific defect. One weekend , Gary spent about a half- hour adding defect numbers to the headers, and that made writing release notes much easier.

Figure 8.3 shows one of our more verbose sets of release notes. This drop contained some new features, but more importantly, it had some infrastructure changes that required explanation.

Figure 8.3. A "detailed" set of release notes for a drop

Figure 8.4 shows a much more succinct set of release notes for a drop. No one would consider either of these examples to be formal. They did, however, do the job we intended them to do ”communicate.

Figure 8.4. A typical set of release notes

Experimenting, Making Mistakes, and Arriving at Our Own Style of Planning

We don't want to mislead you into thinking that one day it occurred to us to plan based upon the Engineering Backlog and Defects tools. We tried several approaches ”including cajoling and pleading ”before we settled on one that suited our small team.

We tried, for a short while, to use well-formed requests (described in Chapter 3). We set up an area on Groove that we could use to create and track our requests. This approach also failed for us. Why? The technique is good and is proven. Some consider it a best practice for team empowerment. So what did we do wrong? Nothing. Using well- formed requests might be a best practice, but it wasn't suitable in our context. The practice proved to be another technique that depended on our ability to commit time that we weren't able to control. The result was more guilt for letting down our teammates. We removed our well-formed request area from Groove. We didn't need the reminder of our shortcomings.

There are a couple of lessons learned in this section. First, when you think about how your environment will change, don't assume that it changes only by addition; it can also change by subtraction. If a tool or technique isn't working, get rid of it. You don't need to clutter up your workspace, whatever form it takes.

The second lesson learned is subtler. Regardless of how good a practice is, and how well it works for someone else or has worked for you in the past, it may not work for you in your current context. The best you can do is learn as many practices as you can, understand when and for whom they work, and then try to adapt them to your situation. If they don't work, don't try to force-fit them ”just discard them and move on.