There is a simple heuristic, which determines the top priority activity you can engage-at any given moment. It comes out of the “lean manufacturing” camp. It applies to a business as a whole, a specific product and its backlog. You typically implicitly apply this when improving software performance.
Your biggest priority at any given moment is clearing your biggest bottleneck. This will give the largest non-linear jump forwards in system productivity, because of the Herbie problem. This includes business productivity (read profit). Cycle time goes down. You reduce “friction” around production.
At the operations level, arguably the single biggest factor which influences most of your metrics is the level of technical debt you have in your software and in your process around maintaining your software (which ideally you can script and turn into software anyway). “Trying to automate your process means really understanding and simplifying your process”, according to Steve Freeman and Nat Pryce in Growing Object Oriented Software.
Even if you have no technical debt in your software, if your release process to production isn’t fully scripted, you have “process debt”, i.e. process that should be simplified, automated, and transparent. As you can probably tell, I really don’t like process. Ideally, your process can be embedded into your company as software. The release process, with CI running a suite of tests, and releasing the software upon sign off by someone important (QA or the product owner). In some cases, this would even mean releasing to production. This is how I guess Dan North’s team released to production 30-50 times a day.
Once you clear a bottleneck, you create another one (a relatively smaller one) elsewhere. This is the nature of the game. Then clearing that bottleneck will give you the highest possible non-linear improvement in the output of the business as a whole. In that context, if you aren’t releasing your software to production automagically with every check-in, you have bottlenecks to clear. “Zip up the man-suit” as the guys on marathontalk.com say. It really is that simple.
Related Posts
- Knowing Your Options’ Value
- Features vs Cycle Time
- The recent Do Much Less Of What Doesn’t Work
Related articles
- Don’t Take the Technical Debt Metaphor Too Far (agile.dzone.com)
- Will software publishers ever shake off their ‘technical debt’? (zdnet.com)
- Productivity (enterpriseirregulars.com)
- Transition to Agile, Large Technical Debt, Small Project (agile.dzone.com)
- Applying Lean to Sales and Marketing (customerthink.com)
- Growing Object Oriented Software Guided by Tests (amazon)
Filed under: Lean, Software Tagged: Bottleneck, Continuous integration, Lean manufacturing, Nat Pryce, Process Debt, Steve Freeman, technical debt