And yet, thrashing is considered unavoidable, just part of the way things are when there is too much to do. It seems that there is no way around it. But thrashing is the result of violating two key Lean principles:
- Working beyond system capacity
- Having delays in your process
The first one is pretty obvious. If you should be working on three things but are actually working on six, you will probably thrash. Let me illustrate. Say you are a developer who needs information about a requirement and you typically get this from a business analyst. If the analyst is not co-located with you, you probably send off an e-mail to her. This may cause a sequence of e-mails between you in your attempt to get the needed information. These e-mail exchanges involve significant periods of time, taking longer to get the answer than it took to write the e-mail itself. This drawn out process causes a lot of waste and a lot of thrashing. Now, how do you solve this? Eliminate the delay. Co-locate with the business analyst. If that is not possible, then talk to them by phone. Do not use e-mails for this type of communication, at least not after an e-mail response shows it is not going to be productive. At the group or organization level, management can establish e-mail protocols and work environments that encourage closer-to-real-time collaboration for this type of work. Yes, it runs counter to how we have grown accustomed to working, but the discipline of avoiding delay through higher bandwidth communication pays off.
Tests Are Defined Too Late
How many times have you seen developers build something only to discover later that what they thought was wanted was not what the customer wanted? Why do our development practices allow this to happen? Often, it is because the acceptance tests are defined after the code is written. This is a violation of the Lean principle of eliminating waste (delay). There is a delay from when the acceptance test would have been useful (before the code was written) and when it was available (after it was written).
One way to avoid this is for a developer to ask the analyst a simple question when tasked with writing some functionality. This question is, "how will I know I have done that?" The answer should provide the developer with a test to see if the function being built is correct. Asking this question before the code is written will make the developer's life both more enjoyable and more productive. Note that asking this question not only gives more information, but changes the nature of the conversation. When the developer is told how he will know, it will help confirm his thinking or show that he is misunderstanding the person making the request.