Why Lean?

Had a great lunchtime chat with Benjamin Mitchell and asked him to argue for lean methods in software development, as if I’d never heard of them. Here’s what I heard:

  • Apply the Theory of Constraints. If a lane shuts down on a stretch of motorway, that bottleneck is the limit on flow for all cars on the road (assuming there are no other obstacles). If you want to keep the maximum throughput, keep cars arriving at the start of the closure at a constant rate – batched delivery of cars to the bottleneck mouth will reduce throughput. This is why you see lots of signs miles before roadworks – you don’t want cars slamming to a halt and trying to switch lanes suddenly just before the lane closure.
  • Use pull techniques. It’s better to focus on what you can finish rather than what you can start (the latter gives you lots of half-finished items you can’t release). Allow idleness if it increases number of items you can finish. Even better if you can pull based on real money committed by a customer, as then you know exactly how to measure success (and you’ve reduced the risk of failure).
  • Work in Progress limits also help you focus on what you can finish and avoid startitis, where you have too much work in your system and everyone churns switching among the overloaded tasks.
  • On idleness: visible, easily-computed metrics like “lines of code typed daily” may look like measures of productivity, but the real measures are generally invisible (though good teams work to make them visible). For example, you really want to know how many of the features you are typing in will actually be used by customers, but you have to change your processes in order to measure this. Lean software development should help you find these measures and make them obvious.
  • Ideas you generate but never develop are another example of real productivity measures (in this case, you want to minimise the metric). Benjamin refers to these “stored” ideas as “bananas” and reminds us that you can store bananas in a warehouse, but only for so long. Similarly, you should dump old ideas that you haven’t gotten around to building (rather than letting them rot in a wiki or ticketing system).
  • You can measure the relative cost of delay in building the features in your backlog, and build those with the highest delay cost (even if they didn’t arrive first, or aren’t the favourite feature of an influential stakeholder). Paired with pulling by committed cash, this should substantially increase revenue.
  • Lean management argues that few constraints are imposed by workers; nearly all are brought about by problems in the process used by those workers. See the Red Bead Experiment.
  • Reacting to obstacles quickly lets you clear them and restore good throughput. Lean techniques like a kanban board help you to do this. (Benjamin is particularly skilled at extracting all the statistical value he can from the available information – ask to see his amazing charts!)

Other useful product-management tips from Benjamin:

  • Take a daily poll on what wasted developers’ time yesterday. Track the results. Top items are worth addressing promptly.
  • Many organisations (often big ones, but not always) reward non-risk-takers. Some organisations (startups, sports teams) reward risk-takers. Few (any?) reward based on end-to-end value, which is really the only important measure.