I attended a session with Mary Poppendieck at NDC today where the topic was trashing in projects. I was a very interesting talk. One of the things that I got out of it, was the notion of churning, which basically is about two things:
- If you have requirements churn, you are specifying requirements too early. Basically, this means that after you write the requirements, the customer changes his or her mind, and the requirements need to be changed before implementation starts.
- If you have test and fix cycles, you are testing too late. In general, testing should be done earlier, and preferably automated
Furthermore, Poppendieck made a few references to classic queuing theory, saying that if the utiliziation of a resource is too high (saturated), the handling time will be lower and result in trashing. Hence, one should no plan for a 100% utilized project resource. The main thing is to optimize on throughput, and not on utilization.