In the previous post in the Twilight Zone series we outlined some pretty serious issues in product development when Batch Sizes increase.  Since we aren’t bomb thrower consultants we hope to provide some practical advice to help reduce batch size.  Of course many of these ideas come from Don Reinertsen’s book, Principles of Product Development Flow, which YOU should read!

We also will showcase the connection between reducing batch size and business areas beyond development.  Our aim is to highlight the need for Lean|Agile thinking to bring agility to the whole organization.

Reduce Batch Size

• Large batch sizes have a lot of bad stuff associated with them.  Some of them include: project slippage due to higher utilization; long feedback loops; high rates of shelfware; and redundant defects.
• So what combats this?
  • Collocation – Batch sizes are proportional to physical proximity.  Close proximity communication among teams encourages smaller batches of information sharing.  You may need to engage Facilities Support to make this happen.
  • Infrastructure – Faster compile, build, integration, and test cycles encourage work in smaller batches.  Think about it, if it takes 30 minutes for a developer to get feedback on his/her most recent committed change, they are likely to batch more changes per commit.  We will probably need to engage Ops for infrastructure support and possibly Architecture to help create more modularized designs.
  • Limit Work in Process(WIP) – WIP is shelfware and any work not delivered to production.  In manufacturing this is equivalent to inventory that clutters the factory floor.  In software, this is equivalent to designs, code, …etc that clutters our minds.  To get rid of this we need Management to understand the cause and effect of limiting WIP.  We also need upstream buyin, because when we Limit WIP downstream, you will cause traffic jams upstream, which will cause Executives, Requirements, Architects, …etc heartburn.
  • Continuous Flow of Value Discovery – Many defects in product development can be attributed to poor value discovery.  Large batches create significant time delays between value discovery and actual development.  The accuracy of the assumptions or information captured during the discovery of value tends to decay over time.  So this time delay introduces bad information into the development process, which leads to defects.  Worse yet, an assumption or piece of information may be redundant across many design decisions which causes a widespread defect.  Therefore, the upstream participants involved with discovering value, typically the Customer, Requirements, Executives, Marketing, Sales, and Product Management, must do this on an ongoing basis to provide as much value information to the development teams.
    • This requires a standardized set of business practices to take in, analyze, prioritize, decompose, sequence and validate work.

So far we’ve identified several business areas beyond Development that influences batch size and ultimately the business agility of the whole organization.  They include:

• Facilities, Ops, Architecture, Management, Executives
• Requirements, Customers, Marketing, Sales, Product Management

While Batch Size is just one of many principles that influences enterprise agility, we hope the Twilight Blog series has showcased how an entire organization influences enterprise agility.  So next time someone suggests that “Agile” only concerns Development…point them to this blog series.

Cheers!