Implementation Accelerates

One primary goal of the Construction phase was to produce a stable Beta release that we could deliver to our user community. The most important piece of the release was the working code. In PSP Tools, the code developed rapidly after we exited the Elaboration phase. For this project, we had already tackled the hardest work during the Elaboration phase. Now it was time to fill in the missing pieces. We had a couple of bumps along the way, but nothing that caused major rework .

Let's look at our starting point. Figure 8.5 shows the PSP Tools main window at the end of the Elaboration phase. You can see that the product is not fully functional. There are aesthetic issues. Few people would want to, or could, use this product.

Figure 8.5. PSP Tools at the end of the Elaboration phase

With the pre-Construction phase version of PSP Tools you can:

• Open an existing project by selecting File > Open and following the prompts. A login dialog box, seeded with the login name you use for the system, prompts you to log in with a user name and password.

• View summary information about specific tasks , related to time and defect entries.

• Create a new task by selecting File > New Task and entering summary information in the appropriate fields.

At the beginning of the Construction phase, it felt like there was a tremendous amount of work left to do. Fortunately, Russell understood that this product wasn't ready to ship ”it was in an early prototype stage. We were comfortable showing him our work and asking for feedback. Too often we hear stories of development teams who will not show early work to anyone , especially sales and marketing people. They are afraid that the people they show it to will start to sell it. Surely this happens, and it builds barriers of mistrust among people who should be working together as one team.

The Fear Factor ”An Example

In contrast to the PSP Tools experience, Gary has experienced one of the ultimate forms of this reluctance to share early versions of a product. He worked in the compiler development group of a large company. This group had a reputation for delivering "world-class" compilers to its customers. The group consisted of a brilliant team of people with extensive experience in building optimizing compilers. At the time, the company was developing a new computer with a completely new architecture. This affected the compilers significantly because they had to produce object code for the new machine. So, the team used an architecture that took advantage of a common code generator, also called the back end of the compiler. This major piece of code needed to be ported for other applications to work. In order for the many company applications to be ported, the compilers had to be available. ^[7]

^[7] This dependency chain is very common in companies that make operating systems and language tools to support hardware they build.

The group that was building the back end for the new computer was working on a highly optimizing back end. The company was making its first entry into the reduced instruction set computer (RISC) marketplace . The team knew that the success or failure of the computer hardware would be dictated by the ability of language tools to optimize their object code.

The back-end group was afraid to release early versions of the code generator, even to internal development groups. They were waiting until they felt it was completely ready for consumption by their internal customers. They were not developing incrementally or iteratively, so they could not release early results. Unfortunately, this meant that they could not get feedback until later in the project. It also meant that the groups dependent on them could not make progress. Why did this happen? In this case, it was fear.

Fear is a major problem for development teams and those managing the teams, and it can come in many forms. In this story, the team members knew that the software would eventually work. They were afraid that early in development, the software would not work as efficiently as it needed to at the final release. The team had a reputation of producing some of the best optimizing compiler technology in the world. Anything less ”any intermediate result ”felt like failure to them. They didn't want to risk tarnishing their reputation for excellence, regardless of their users' actual expectations.

The story has a happy ending, but it was achieved with much anxiety and tension. Gary was managing one of the projects that needed the code generator. He tried every one of his silver-tongued (said tongue-in-cheek) techniques to cajole the code generator team to deliver an early release to his project. Finally, in frustration, Gary offhandedly threatened to have one of his engineers write a "quick and dirty" code generator, using the API specification for the new code generator. Gary has experience building compiler back ends and knew it would be a small effort to produce something that would be good enough for early engineering efforts. The code would be horrible, the applications would run miserably, but they would run! That's all he wanted.

This suggestion got the attention of the code generation group. Reluctantly, the manager of that group had one of his staff "throw together" a code generator. The manager felt it was better to have someone who knew the code build the generator. If one of Gary's engineers wrote it, there would be several undesirable effects. The code generated would be as bad or worse than what the back end team would produce and it would probably be buggier. The back end team would be blamed for it anyway. A fear might emerge that they would be unable to deliver the final code generator. Perhaps most disastrous to the back-end group's reputation would be the questions raised about what those developers on the back-end team were really doing.

As a result, a code generator was delivered for internal use within a week. It was good enough for the rest of the projects to use to ensure their product ported to the new hardware. A large amount of documentation accompanied the delivery, mostly consisting of disclaimers that the code generator was delivered "as is" with no warranties, guarantees , or support. Attorneys would admire the rigor of the documents and disclaimers. Gary sometimes wonders whether some of the engineers in the group have moved on to legal careers, or to writing disclaimers for adult Web sites.

A Better Way to Deal with the Fear

The story about the fearful compiler group provided a detour on our Construction phase journey. But it does illustrate a common problem that occurs on many projects. As a project manager or team member, how can you mitigate the risk of not delivering anything because of fear?

We have a few suggestions. Maintain continuous communication with your whole team, including stakeholders, customers, development team, and managers. If your team members can quickly assess the current state of the project at any time, they are more likely to have proper expectations about what each product build will deliver.

Developing your software iteratively and incrementally, and making it available for anyone on your team to use, is also important. Welcome participation, even if expectations are high. Offer to help users install or use the product. Listen to problems they have or expectations that aren't met. Help them understand exactly where you are in the project and what your goals are. Good communication is essential throughout the project; this is just another example of how it benefits your team.

Another Short Tale

When Bob Martin of Object Mentor gives presentations on XP and agile methods , he often uses a story about working on a project that would help architects draw designs on a computer. The team decided to produce weekly iterations. In each iteration they would add more functionality so that the product would continually evolve . Further, they would get user feedback at the end of each iteration.

For the first iteration, the team produced a blank screen with some color and a menu bar that did nothing. Bob showed it to the customer who repeatedly asked "Is this all it does?" and "It'll do more than this, right?" Bob explained that there would eventually be more, but that the team would value some feedback from the customer. Bob kept asking, "So what do you think about this?" Finally the customer settled down enough to look at the first iteration's build and made a couple of suggestions about the order of menu items and so on.

In the next week's release, the customer saw that the menu bar actually worked and the changes he suggested were implemented. You could click on menu selections, but nothing happened then. There was a little palette with icons on it that did nothing. The same scene took place. Again, at the end of it, the customer made some suggestions for the team and the next iteration began .

This was the rhythm of the project. As the customer got more familiar with the process, he became more comfortable. He was able to see real progress and he always knew what the product was capable of doing. On our own projects, we should all strive for this level of openness with our customers and stakeholders. Open communications help build and maintain one of the most precious elements for success ”trust.