As a Lean proponent I talk a lot about speed. Lean says to focus on time not resource utilization. That is, we want to shorten the cycle time of our value streams (that is, the time from when we start to when we deliver value). It also suggests that most problems are systemic – so when they occur we must fix the problem – view it as an ongoing impediment - and not merely work around it.

I've been working with a lot of Scrum teams lately.  Many people hear going fast as hacking.  Of course, it can be if one is just trying to get to "code complete."  In the past I've explained how "optimize the whole" means speed has to be considered from the entire development cycle - and therefore hacking would not be considered as going fast as it slows things down later (either in QA or in maintenance after release).   

Saying, however, you want to go fast, can be misleading. You want to end up having gone fast, but that doesn't necessarily mean that you had to be going fast at any one time. Huh? Imagine this, let's say you have two ways to get from one city to the next. One way has a lot of expressways, but also goes into some places where you have traffic jams as well as some detours. Half the time you'll be going very fast (60mph) but some of the time you won't be going at all, and some of the time you might even be going in the wrong direction! Now, going faster on the expressways may not help.

The alternative route may have you never go more than 40mph. But if you can eliminate the delays of the traffic jams and avoid the detours, you may end up going where you want to in less time (that is, faster). And probably with less stress.

When we talk about delivering fast in Lean, we mean the total time taken to deliver is faster than non-lean methods. But we get there by eliminating the waste of delay. Hence, we are not introducing problems by going too fast, but rather are eliminating problems of going slow when that hurts us.

Alan Shalloway

Technorati Tags: Lean Lean-Agile

tag with del.icio.us