Tutorial – Lean Software Development

I attended this tutorial because I’ve always been interested in the Theory of Constraints but have had problems relating how it could be applied to software development. This may be in part due to the fact that I haven’t read Lean Software Development by Mary and Tom Poppendieck. My hope was that attending a ½ day distilled introduction to Lean by Mary Poppendieck would effectively alleviate this.

The Lean principles presented in the tutorial included:

  • Just-in-time flow – A local optimization does not result in a global maximization. You need to look at the system as whole, not at maximizing resource utilization.
  • Maximize the flow of value and minimize churn. Two examples that were given in software include:
    • Test and fix cycles is an indication that you’re testing too late.
    • Requirements documents going through edit and update churn is an indication that specifications are being written too early.
  • Minimize waste – Anything that does not contribute directly to customer value is waste. Requirements docs are a good example as they are necessary but don’t contribute directly to customer value.
  • Cycle time – The average end-to-end process time, from when a customer identifies a story to when the completed functionality is delivered to them. Key concepts include even out the arrival of work, minimize the number of things in process, minimize the size of things in process, establish are regular cadence, and use pull scheduling.
  • Simplicity – Minimum useful feature sets, common architecture and tools, and refactoring.
  • Mistake-proofing – One click build, continuous integration, automated testing, frequent deployment.
  • Change-tolerant practices – Test driven development, iterative development, maintain options.
  • Engaged people – Move responsibility and decision-making to the lowest possible level, self-directed work, and teams, not work groups.
  • Relentless improvement – Regular work team meetings, data-based problem analysis.

I was certainly left with the impression that there are a lot of common elements between Lean and i-Proving:

  • Customer collaboration, iterative development and focus on testing help minimize churn.
  • Customer collaboration and planning with stories help minimize waste. i-Proving teams are always focused on delivering customer value.
  • Iterative development, frequent releases and minimizing the number of stories open at any one time help to even out the arrival of work, minimize the number of things in process, minimize the size of things in process, and establish regular delivery cycles.
  • i-Proving technical/engineering practices such as automated testing, continuous integration, simple design, refactoring, and frequent builds help maintain simplicity, change tolerance, and mistake-proofing.
  • Sustainable pace, co-located teams and task pull help keep people engaged.

The only facet of Lean that I think we could improve on is relentless improvement. I think we could do better with project/iteration retrospectives, root cause analysis and using feedback loops to apply what we have learned to improve.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply