Wednesday, September 24, 2008

Seven Principles of Lean Software Development - Deliver Fast

Picture courtesy of johnthescone@flickr
Work in small batches
I've always thought that delivering small pieces of software is easier than delivering the BIG BANG product at once. Small software package is easier to manage than the big one, you can expect smaller amount of defects there, it is much easier to integrate it with existing software. Isn't that obvious?

On the other hand working on the new version for, let's say, six months without regular integration in the production environment (if integrated at all) will bring you much more problems. Defects will accumulate and just before the release someone will discover them. No surprisingly developers would have to work overtime to fix them.

More so, let's say that you have to spend always additional 10% of time on integration and bug fixing of delivered package (working either on small or large batches). If you deliver products each 4 weeks (20 days) fixing and integrating the package will take you two days (for the customer it's almost transparent - nobody will even notice two-day delay). If you deliver new versions each 6 months (130 days) fixing bugs and integrating the product will take almost two weeks (if defects will not accumulate) - your customer could go mad about it.

That's why you should reduce projects size, shorten release cycles, stabilize work environment (listen to what your velocity tells you), repeat what's good and eradicate practices that creates obstacles.

Limit work to capacity
According to Mary and Tom Poppendieck you should limit tasks queue to minimum (one or two iterations ahead is enough). You should not be afraid of removing items from the queue - they even claim that if you remove something important it will not do any harm because your customer will remind you about it pretty soon! Keep only important, valuable and urgent items there i.e. features that bring biggest business value to your customer.

Give your team some time to stabilize velocity, to see how much you can deliver each iteration. This is the only reasonable and REAL value. You cannot assume that your team will deliver twice as much next month - you know your capacity. Expect your team to pull items from the queue based on measured velocity and to completely finish the work before they move to the next ones.

Moreover, you should reject any work until you have an empty slot in your queue. It is really great tip because it doesn't make sense to add items to the backlog if you know you won't have time to implement them, unless you want to add something more important than items that are already there.

Focus on cycle time, not utilization
Many software organizations want their engineers to be utilized at 100%. It's not a good idea, though. Take your computer for example or server machine. What do you think if its CPU is utilized at 100%? Yes! You try to figure out what process you can kill to reduce the utilization.

Full utilization creates traffic jams which in turn reduces overall utilization. Queuing theory applies here i.e. you should put in your queue small tasks that cannot clog the process for a long time. You should reduce cycle time and have fewer things to process in your queue.

Also, instead of worrying about the resource utilization you should start measuring time-to-market and customer response time. Smaller the batches and shorter the cycle time the smaller those values will be.

Wrap up
I hope pieces of advice given above will make it easy to understand how to put "Deliver Fast" principle in practice. If you need more detailed description with more examples and more sophisticated explanation you should definitely go to "Implementing Lean Software Development - from Concept to Cash" book.

Originally published on AgileSoftwareDevelopment.com

No comments: