Methods have a, well, method of taking over your life. Soon you are concentrating on artifacts since they are required in some way, instead of concentrating on implementing the product. This is why programmers like XP: less weight is given to prose products and more to code.
One very good part of the Team Software Process (TSP) is the Launch. In addition, another two of the pros for requiring it are the weekly status meeting and a tracking tool. These all help start the project and keep it going. In fact, one of the most difficult aspects of a software engineering project is getting started. Some managers believe that getting started is everything, so they impose a method from above. In fact, TSP is so good at encouraging the production of artifacts (that are not code) that it is often imposed. It is easy to confuse the production of artifacts with the production of the product.
There are several reactions possible to the imposition of a certain method. The most serious of these is when engineers are intelligent and reject the method as a result of ego (see Chapter 3). They may perceive any method as too confining and refuse to produce deliverables, preferring to keep procedures in their head. Tomayko noticed this when he worked a lot with configuration management [Tomayko 02]. The theory was that no programmer would make any changes to anything until after the Configuration Control Board (CCB) authorized it. At first, the bright programmers anticipated what would be approved, so they could secretly begin work on the changes. Eventually, they did not wait for the CCB to meet; just kept making changes to defects as they came up. Changes to documents were ignored.
In fact, Watts Humphrey of the SEI once said, Your real process is the one you follow once you are behind schedule. This means that no matter what method is being used, it goes out the window once programmers perceive the schedule is getting away from them. An effective way of saving time on documentation artifacts is not to start them in the first place. This effect is primarily the reason why some code is costly to repair or otherwise change later: it lacks up-to-date documentation and must be reverse engineered.
This is why we believe in lighter-weight methods with fewer artifacts. The required items are so light that there is time to actually accomplish them. They can also be done at the appropriate time. The design, say, is described near the end of the project, when further changes to it are unlikely . The major difference between established methods and lightweight methods is that in heavyweight methods, artifacts are due at times and in a form that requires them to be changed. Lightweight methods require fewer artifacts, and requires them when what they are documenting is complete, so fewer or no changes are required. This makes programmers quite happy. They find themselves wasting little or no effort. Actually, in a world of better, faster, cheaper, managers like this format, too. Therefore, if any method is being required, an unobtrusive method is best. Engineers like those best because they seem to require the least work.
List deliverables from a heavyweight method. Mark the ones needed for maintenance and specify at what life-cycle phase they can be written.