Lean Anti-Patterns and What to Do About Them

causes, and then address the root cause. That will lead to fixing bad practice. Toyota calls this having a quot;stop-the-linequot; mentality. When there is a problem, stop the production line, identify root causes, fix it, and then go on. That is how you drive out impediments from your process for the long term.

Three Common Lean Anti-Patterns
My colleague Jim Trott and I have identified 29 anti-patterns in the areas of enterprise organization, project management, requirements and analysis, design and code, and quality assurance. [4] These are a start, and we are sure there are more. As examples, let me describe three that are all related to delay:

• Individuals thrash on their tasks

• Tests are defined too late

• Optimizing QA

Individuals Thrash on Their Tasks

Almost everyone in a modern organization has experienced thrashing on tasks: there are so many things to do that you end up going from one task to another before finishing the first task. This is called quot;task-switching.quot; Each time you switch tasks, you have to stop what you were doing and then take time to start focusing on the next task. When you come back to the first task, you have to take time to remember where you were before you can start up again. The term quot;thrashingquot; comes from when computers had so many processes, the overhead of switching between tasks took more time than the work itself. That is just what happens to us.

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