Simplicity Factor: Batch Size

This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.

 

Back to Dealing with Complexity by Creating a Bias For Simplicity 

Why look at this

Often reducing batch size is all it takes to bring a system back into control – Dr. Eli Goldratt

One of the mantras of Flow and Lean is to work on small batches. Attending to batch size is important for several reasons. The most common one is that small batches can be done quickly, are easier to manage and can be delivered to customers quickly. But small batches also force product managers to focus on what’s most important. This is essential when trying to sequence work. When there are conflicts as to how to allocate capacity to different work items, using large work items complicates this because not all of one work item is more important than all of another work item.  When a new product is being created MVPs are quite useful and start us with small pieces. But we often have large initiatives that relate to existing products or services. In this case we have to break these initiatives into smaller pieces – Minimum Business Increments.

it is important to understand that batch size occurs at different levels. We have both the specific size of the items being worked on as well as the total amount of work in process. For example, in a Scrum team, the size of the story is the batch size being worked on the the Sprint backlog is the batch of work to be accomplished. Both “being worked on” batch size and “work in process” batch size are important to attend to.

When batch sizes are too large:

  • it causes people to be less effective
  • it causes delays in the workflow and in getting feedback which creates waste
  • it delays the realization of value
  • it makes it difficult to collaborate

Desired batch size by level:

  • being worked on by an individual (e.g., story) – less than three days
  • work in process for a team (e.g., team backlog) – less than 2 weeks
  • work in process for an organization – 1-3 months, the smaller the better

Symptoms that your batches are too large

  • People working on too many projects
  • Work taking much longer than it should
  • Projects being worked on by many people part time

What causes this

Common causes are:

  • not using minimum Business Increments
  • not developing in small increments
  • not managing dependencies between teams making it difficult to decompose what needs to be built

What we want to achieve

Working on small batches at the different parts of the value stream. At the intake part of the value stream we should be using MVPs and MBIs. At the program level, we should be having small components that can be built and validated. At the team level we should have as little work in process as possible while keeping people productive.

Common solutions

  • use MBIs to have smaller batches coming in
  • decouple teams so the total work in process can be lowered
  • have cross-functional and dedicated product teams so fewer items so batches coming in can be completed quickly
  • An essential one is using MBIs.
  • Create visibility on all work in the system
  • Right-size the work waiting to be started using MVPs, MBIs, and MVRs appropriately
  • Sequence work to be pulled
  • Create a focus on finishing (see Manage Work-in-Process (WIP) by Focusing on Finishing  for more

Other simplicity factors that are directly related to this one

  1. Batch size of work
  2. The value density of the items being worked on
  3. How workload relates to capacity
  4. The value creation structure of the organization
  5. Effectiveness/efficiency of the value streams
  6. Visibility of work and workflow 
  7. Quality of the product
  8. Culture of the organization

This chapter was an excerpt from FLEX for the Disciplined Agilist: FLow for Enterprise Transformation (online book). It has been edited to fit into the Disciplined Agile Value Stream Consultant workshop. The Table of Contents for the book is here.