I’ve been trying to apply lean software development principles on my project for a little over a year now. So, when I recently re-read Mary Poppendieck’s Lean Software Development – An Agile Toolkit, I thoroughly enjoyed it and found I was nodding to myself a lot. I highly recommend reading this book because it explains in very simple terms what this whole lean process thing is about, and how it relates to software development. A knowledge of why Agile processes work and what they’re aimed at would help, but is not essential.
For those who don’t have the patience (or time) to read the full book – here’s my version of a summary –
– Strive to eliminate waste. Waste comes in many forms in the world of software development, all of these is waste – partially done work, extra processes that add no value, extra features that have little impact on business value, task switching because of multiple objectives or other reasons, waiting for something, having to go somewhere (to meet someone or fetch something) to get information, defects, and ‘management’ activities.
– Use a technique called value-stream mapping to understand where the process you’re using delivers value and (more importantly) to determine where it adds none.
– Amplify learning through feedback. This is easily done through short iterations and negotiating scope for each of them.
– Think about set-based development techniques.
– Delay commitment – decide as late as possible. At the same time, think about concurrent development.
– Understand the cost of delay – use a product model. Have an accountant on your team who can help with this, and make trade-off decisions in light of what the model says.
– Empower the team!
– Think about integrity – both conceptual integrity, and perceived integrity.
– Testing – TDD, automated functional testing, continuous integration – is key. Refactoring is key.
– Always optimize at a level higher than the perceived issue. Employ systems thinking.
– Embrace the idea of Customer Collaboration vs. Contract Negotiation.
I’ve found that as I started to apply lean software development methods, our processes started to become more and more natural, and that the team became more and more effective. As expected, the team members themselves began to look for new and innovative ways to optimize their workflow, and my job as a project manager became easier and easier from that perspective.
Speaking of optimization, I recall being introduced to the writings of Eli Goldratt by a really smart project manager I worked with in the past – Matt Gelbwaks. Goldratt writes about the Theory of Constraints – his books The Goal and Critical Chain are a really good start to the whole discipline. He has a really simple algorithm to optimize a system, based on throughput accounting –
1. IDENTIFY the system’s constraint(s)
2. Describe how to EXPLOIT the system’s constraint(s)
3. SUBORDINATE everything else to the above decision
4. ELEVATE the system’s constraint(s)
5. If in the above process, a constraint has been broken, GO BACK to step 1 but do not allow inertia to cause a system’s constraint.
Applying the Theory of Constraints to improve my teams’ processes, while using lean software development ideas to drive agile practices has proved absolutely invaluable to me over the past year.
I’d be happy to hear from you if you tried similar things on your project… and about how they worked out…