Weight Loss For Software Development

Mary Poppendieck opened STAR East this morning by asserting that “Your development and testing processes are defective”. Mary has long been a proponent of lean software development. She maintains that if you routinely find defects during verification you have a defective process, because defects are caused by a system which allows defects – not by developers – and are a management problem.

Mary offered four suggestions for putting your software development process on a diet:

  1. Eliminate waste. Focus on what adds value for your customers and drop everything else.
  2. Don’t tolerate defects. Inspect to prevent defects, not to find them. Don’t just log bugs but rather fix them as soon as you find them.
  3. Don’t batch and queue. Don’t leave bugs lying around; either fix them or Won’t Fix them the moment they come in. If you have requirements churn then you are specifying too early, and if you have test-and-fix cycles you’re testing too late.
  4. Optimize the whole. Optimize the whole product, which is not just software but a comprehensive solution that solves a customer problem. Optimize your whole team: Dev and Test and Program Management, not just Dev or Test or PM. Optimizing for point productivity drags down overall productivity. Counterintuitive though it may be, letting one group go idle for awhile will often speed up overall throughput.

This sounds simple, but it’s really complicated. It sounds complicated, but it’s really simple. So what’s stopping you?

Comments (2)

  1. How is this different from Agile development? In the current feature crew model for Orcas, is this not what we have set out to do?

    However, I would like to know how you think testers can do software inspection effectively and real world examples if you had any. I am trying to get my team to do code and spec inspection for the coming product cycle and would really love to know any best practice around that.

  2. Lean is one form of Agile, so in many ways Lean isn’t any different than Agile. The new feature crew model that DevDiv has started using is a great move towards Leanness. We still have a ways to go however – especially in the Fix Or Won’t Fix Right Now area.

    There are several good books on code inspections; Keith Stobie has published some great information in this area as well. The way to start, though, is to just start. Grab that spec and go through it line-by-line, by yourself to start with and then in a group. Code can be harder to inspect, just because you have to figure out what it’s doing. But that can be a good thing – if you can’t figure out what the code is doing then you know something very important about that code!

    No specific examples come to mind just now, but I’ll add them later if I think of any.