Page 103 -

If the project team had inspected the use cases, this could have been avoided. Everyone
with a stake in the project—including QA team members—would be invited to the inspec-
tion meetings, and each inspector would have a better idea of what to look for during the
inspection process. It costs the same to build the right software as it does to build the
wrong software. A few hours of searching for and fixing any problems with the use case
document would have saved the team weeks or months of rework.
Big, Useless Meetings

Having a project fail due to a problem in a document that isn’t caught until late in the
project is traumatic for a team. It’s especially bad for the person who wrote the document.
Once a team experiences this problem, everyone feels especially motivated to do some-
thing about it. In many cases, the solution that seems most obvious to the team and the
project manager is to distribute the responsibility for creating the document. The last
project was a mess because the team missed something; there’s no way that they will let
this happen again.

The project manager calls a meeting to get everyone together at the very beginning of the
project. He takes no chances, inviting everyone who might possibly have some small input
into the project and impressing upon everyone just how important the meeting is. An
entire afternoon is blocked out for a standing-room-only session that’s supposed to let
everybody have a voice in the design of the document. Unfortunately, it ends up having
the opposite effect.
Everyone has something to say, and nobody wants to let any stone go unturned. The big
meeting seemed like a good idea on paper, but it quickly gets bogged down in details that
only one or two people care about. The meeting goes nowhere. Nobody knows what they
are supposed to do, and there’s no real leadership or direction. Long after meeting fatigue
sets in, no progress has been made. Stakeholders are arguing about the minute details of
the day-to-day business of the organization, while designers are caught up in potential
design problems, programmers can’t decide on which tools to use, and, through all of this,
nothing is written down. The team adjourns the meeting, having made no progress. After
a few tedious marathon meetings, the project team gets sick of waiting and decides to do
things the way that they’ve always been done.

Had the team held an inspection meeting, a deskcheck, or a walkthrough, everyone would
have understood his or her role. The reviewers would have been more carefully selected.
A single lead author would have had the responsibility of generating the document. Each
reviewer would have had a well-defined role, reading the document and bringing up spe-
cific defects. Each defect would have been discussed by people with some knowledge to
address it, and the responsibility for finding the errors would rest with the people capable
of fixing them.

The Indispensable “Hero”
Sometimes a programming team has one “hero” who seems to stand out above everyone
else. If a technical problem comes up that nobody can solve, and it looks like the deadline

REVIEWS 95