Bottlenecks

I’ve been reading though Implementing Lean Software Development as a member of the San Antonio Tech Book Club. Bottlenecks are discussed in Chapter 7, and I had some notes/reflections on the subject…

Lean suggests that it’s important to figure out, and focus on the main problem.  This is an idea we know from optimizing our programs, for instance, if a query is 55 out of a 60 second operation, the thing to optimize is the query-optimizing anything else isn’t going to make much difference.  Similarly, if an app spends a week in testing, and 6 months in approval, making even huge improvements to finish testing earlier can make at most 1 week’s difference in the final delivery date-but even a minor improvement in the approval process can save several weeks.  Maybe the biggest bottleneck is a tough task-but it’s a task that has the potential to make the biggest real difference. 

Addressing bottlenecks isn’t easy.  To correct a problem, you’ve got to accept it as true, and take ownership.  Think about that-ownership doesn’t mean denying the problem exists, making excuses or the problem, or blaming the people who set up the current system initially, it means saying this problem is my problem.  It doesn’t mean taking the blame, or even denying blame. Blaming doesn’t solve problems, removing the root cause solves problems. 

When working on removing a bottleneck, sometimes the first approach doesn’t work.  Continuously and honestly evaluating the success of new approaches is crucial-it’s equally important that though we take ownership of a problem, we don’t take the results of a particular new approach personally.  If we become overly attached to a failing approach, or even a successful approach, we won’t be open to a newer, more successful approach, and worse, we might even see the newer approaches as a threat. 

Perhaps the prerequisite to all of this is organization-wide commitment to eliminating bottlenecks.  The biggest hindrance can be anywhere between initial request and final delivery, and without an org-wide commitment, it might be impossible to make changes needed to solve problems, and it might even be difficult to identify what the true problems are.  Your team may be optimizing the heck out of itself, but if there’s a bottleneck elsewhere, those efforts might not be having a noticeable effect, and depending on the situation of the real bottleneck, those small-scale efforts might even be making things worse. Why waste that effort?  Make things better, but make sure you’re really making them better.