What Are Lean Anti-Patterns?
Lean is the label for a way of thinking pioneered by Toyota in its approach to designing and building cars. Womack and Jones[1] extended this way of thinking, coming to view Lean as a process of "fast-flexible-flow" to convert concepts into cash quickly and sustainably. Mary and Tom Poppendieck[2] applied these ideas to software development, developing the notion of Lean Software Development. An "anti-pattern" {sidebar id=1} is a way of doing something wrong that commonly occurs again and again. An anti-pattern is not exactly the antithesis of a "pattern"; which can be considered as a solution to recurring problems within a context. Patterns focus on solving problems whereas anti-patterns focus on bad practices.
A Lean anti-pattern, then, is a commonly occurring bad practice that violates Lean principles, that works against the organization seeking to become Lean. An example of a Lean anti-pattern is Regression Deficit Disorder (RDD).[3] RDD occurs when features are added without adding automated acceptance tests. Over time, this leads to regression testing that takes longer and longer. And costly testing makes it just that much harder to do quick releases. And that delay makes it just that much harder for the organization to deliver value to its customers quickly. Such waste is a shame. Why do I call this a Lean anti-pattern? Because the bad practice—no automated acceptance testing—violates basic Lean principles (how they do that I will leave for you to consider):
- Optimize the whole
- Deliver fast
- Eliminate waste
- Build integrity in
The Value of Anti-Patterns
The value of anti-patterns is not to identify bad practices. That is the easy part. An anti-pattern exists because of a violation of some underlying principle. They give you a way to understanding the deeper issues that are involved and that gives you a handle to think about what to do. Thus, the key to fixing ineffective behavior is to identify the principle(s) being violated and to stop violating them.
This article suggests using anti-patterns to improve performance by:
- Finding non-productive actions that are being done.
- Identifying the principles being violated.
- Seeing other ways of doing tasks that do not violate these principles.
Of course, this is easier said than done. Sometimes, you do not have control over what needs to be done. In these situations, you can use the principles to help those in control to see what is going on and encourage them to change their actions. Additionally, and perhaps more importantly, recognizing the principles being violated helps you see what you can do within your own sphere of influence. You are equipped to see in new ways: how often we are aware of ineffective behavior but justify it by saying, "Well, this is just the way things are; we do not want to be satisfied with the status quo!"
Why Focus on Lean Anti-Patterns?
Now, given that you are trying to do Agile development, why should you focus on Lean anti-patterns? People who study both Lean and Agile soon realize that Lean provides a set of principles that assist in the adoption of Agile practices. Violating Lean principles guarantees that you will have bad Agile practices.
Simply tweaking a process as a quick response to fix some sort of bad practice may never fix the true problems. That approach rarely addresses the underlying root causes. That is why Step 2, above, is so important. Start by looking at the impediment, the practice or whatever is getting in the way. Then, use anti-patterns to help consider the principles being violated and thus to identify root causes, and then address the root cause. That will lead to fixing bad practice. Toyota calls this having a "stop-the-line" 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 "task-switching". 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 "thrashing" 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 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.Optimizing Quality Assurance
How can optimizing Quality Assurance cause problems? Teams often try to optimize QA because it is over-worked. They batch the tests so QA can be more efficient. But this causes delays from the time the developer is through writing their code until it gets tested. This makes it harder for developers to fix any problems that are found which results in more problems. It becomes a vicious cycle.
A core Lean principle is to optimize the whole. In this situation, Lean would have us integrate development and QA. This would lead us to move test definitions to the front. It should lead to having automated acceptance tests or, at a minimum, to incorporate the discipline of asking—and answering—the question, "and how will I know that I have done that?" as I described in the earlier anti-pattern.
Conclusion
Lean anti-patterns describe violations of Lean principles that are evidenced by bad practices. They serve as reliable guides to more effective process improvement and to better practice. The way to use them involves a three step process. First, identify a bad or ineffective behavior, because it is usually easier to see the negative than it is to identify what to do right. Next, use the anti-pattern to understand root causes by considering the Lean principles that are being violated, as evidenced by the bad behavior. Finally, develop approaches that address the root causes and will create more effective practices.
[1] Lean Thinking by James P. Womack and Daniel T. Jones
[2] Lean Software Development: An Agile Toolkit for Software Development Managers by Mary Poppendieck and Tom Poppendieck
[3] Tom Poppendieck coined this term in a conversation with Mary Poppendieck and Alan Shalloway.
[4] More information will be available in our upcoming book, Lean Anti-Patterns and What to Do About Them.
