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.


Posted 07-22-2009 12:46 AM by Anne Epstein
Filed under:

[Advertisement]

Comments

Jason Meridth wrote re: Bottlenecks
on 07-23-2009 8:50 AM

I agree completely with not blaming anyone and taking ownership.  Rule #24 from the Pragmatic Programmer book is:

"Fix the problem, not the blame: It doesn't really matter whether the bug is your fault or someone else's -- it is still your problem, and it still needs to be fixed."

Also, a co-worker's favorite line:

"I'm not married to the code"

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)