Raymond Lewallen

Professional Learner

August 2008 - Posts

An entry into lean

I, like many others, have been head deep into lean methodologies such as kaizen, kanban, 5S, value streams and lean in general. As I continue to learn and practice these things, I’m going to start publishing, much like Laribee is with his focus on Kanban, in order to gain feedback and ideas. I’m going to cover things in a bit more general matter than just approaching one methodology, but hope to hit on them all.

Today I just want to give a primer into lean so those of you who haven’t done much reading into it have a foundation from which we will build.

When you hear lean, its difficult not to throw the word efficiency into every sentence under discussion. Efficiency is a metric and is easily measured for most things. If your car is rated to get 20 MPG and you are achieving only 15 MPG, then your car is 75% efficient as it relates to its gas mileage.

Efficiency has its counterpart, however, and this is waste. Many people will tell you lean is about eliminating waste, but that is not entirely true. Lean is about improving efficiency, and waste elimination is typical the least expensive, most effective way to improve efficiency, but its not the only thing. Thus, don’t focus soley on waste elimination, but on the improvement of efficiency itself. For developers, obvious waste is easy to spot. Phone calls, emails, ESPN.com and things of the like are main culprits. You have to stop and ask yourself and evaluate each activity: does this activity help me achieve my goal for the day as it pertains to adding value to my client/product/service etc. Identify – correct – sustain.

Kanban, as Dave has been implementing, is one system that helps with waste elimination by having a feedback loop and a continuous work flow by pulling downstream from upstream and current status evaluations. Other methodologies have different principles behind them, but to achieve the same goals, and I will be talking about those as they each are forms of lean used to Identify Inefficiencies – Make Corrections – Sustain Positive Process Improvements.

Lean literature is everywhere. Take some of the keywords I’ve talked about here and search the web for them. You’ll find lots of great information.

Posted Aug 28 2008, 08:50 AM by Raymond Lewallen with 2 comment(s)

Filed under: Lean

The Fly in the Soup of the Iteration

Where do bugs fit into your iterations? This is a discussion I’ve had on many occasions with many different people. Laribee mentioned they work bugs as soon as they come in. I believe Bellware told me the same thing. Provost and Newkirk both told me they get bugs prioritized into the backlog along with everything else as they come in, and they get estimated and put into a specific iteration along with the stories.

I’ve tried it both ways. On the same project even. We have gone from working them into the iteration, to doing them when they come in, back to working them into the iteration. We weren’t as successful as we would have liked either way. Bugs are always hard to deal with, because you don’t exactly know what’s wrong and everything is just guesswork until you go in and look. And by the time you go in and look to see what could be the problem to estimate how long its going to take to fix it, you find out the majority of your bugs take a change to a single line of code (of course, write your unit test first to simulate the bug and fix the code). 90% of your time is spent figuring out what is causing it. This is where the estimation of bugs has to hit, on the figuring out, not necessarily the fixing.

So how to handle this? Well, you have to mix together a few different strategies in reality. Some bugs will come across in the bug tracker as high priority, things that are hurting the production system and must be resolved within the next few days. Many others will not be as high priority. What my team does now, and it has worked very well, is when a critical bug comes in, the next person to finish a task will pick up the bug and work it. All other bugs go into the backlog. At any given time we have between 10–15 bugs in our backlog. These are bugs that get worked on Friday mornings and afternoons as the iteration winds down and stories become completed and resources become available. This has had very little impact (no noticable impact, actually) on our velocity and backlog curve. So in the end we are not really estimating bugs. For metrics purposes, we only keep track of a bug count, not an estimated velocity of what it would take to resolve a stream of bugs.

Short iterations, another topic I’ve been meaning to talk about, certainly helps deal with quick turnaround on high priority bugs. If you are working 4 week iterations, the turnaround on a bug is horrendous unless you branch, resolve, merge… puke. Either way, its still several days to get the bug out at worst case, which is no different than just working 1 week iterations.