a sample of the total code, and base the decision on whether or not to continue inspections on the results of the sampling. We had good numbers on the cost of defects found in test, so it would be a straightforward data analysis to determine whether or not to continue. The conditions to which we agreed were:
- The code samples would be a representative sample based on complexity.
- The team would faithfully adhere to recommended preparation and inspection rates.
- The team would collect the data accurately.
Because this was another very complex product, it wasn't surprising that the defect rate for the inspected code justified continuing inspections.
To say we fooled the manager might be a little strong, but we were reasonably certain of the outcome and the team members were motivated to do their best to justify their positions. Keep in mind, this was not a scientific experiment, but an experiment to justify continuing a process (i.e., participants were not unbiased).
Lesson Learned #5
- In the face of resistance, propose a low-cost experiment (such as sampling) to evaluate use of the proposed process or idea. It does not necessarily have to be a fair experiment either. (Accurate, yes, but it doesn't have to be fair. Think of it as gambling when you are the only one who knows the outcome is a certainty.)
In each of these examples, understanding what makes your boss tick is critical to getting your way. Giving up, calling him an idiot, or assuming he would not recognize a good idea if it hit him between the eyes are all forms of transferring the blame to someone else. Remember that when you are proposing a change or new way of doing something, you bear the responsibility for selling that idea to the decision makers. To do this effectively, you need to understand what they react to or are paid to do. Once you understand that, it is a lot easier to get your way.