In the previous post in the Twilight Zone series we highlighted the misconception that Agile is for software development only. In this post and subsequent posts we will highlight how Batch Sizes are effected by many areas across an organization beyond development. Put your chin strap on…this may get a little heavy!
Don Reinertsen’s book, Principles of Product Development Flow(YOU should read it!) lists Reducing Batch Size as one of the eight principles of product development flow. Before we jump to how you can reduce batch size, lets take a look at the cause and effect of large batch sizes. By the way…much of this content can be found in Reinertsen’s book. Did I mention YOU should read it?
The Cause
Today most project management is focused on wringing out efficiencies by institutionalizing large batch sizes. This leads organizations to functionally align into big batch silos – Requirements, Architecture, Development, Test, and Operations. The thought is that we can gain efficiencies through economies of scale and uninterrupted work. And guess what…its true! There are local efficiencies gained by pushing large batches of work through functional silos. But how does this effect the agility of the whole organization?
The Effect…let the games begin!
- Increased cycle time(i.e. slower delivery speed.)
- Its gonna take longer to build more stuff – duh!
- Increase variability of flow
- What’s that mean? It means there will actually be more frequent and larger interruptions in work.
- Think about it, every time a big batch of work enters a silo a flurry of activity must happen to service it. When a big batch leaves a silo, activity subsides. Hot, cold, hot, cold, …etc.
- Slower feedback
- Check out the Time to Feedback blog
- More risk
- The longer it takes, the more could change(requirements, customer, technology, …etc)
- Big planes are harder to land than small planes (btw…in the English language we call that an analogy 😉
- Slower feedback increases the consequence of errors. i.e. the later we learn about a problem, the more it costs to fix it.
- More overhead
- More uncertainty in process means more status meetings so we can get updates on our uncertainty. Making sense yet folks?
- Reduces efficiency
- Wait I thought it gained efficiency? Well…yes…locally! However its at the expense of destroying important feedback loops that cause defects to grow exponentially as batches are pushed through each functional silo.
- I know this never happens…but what if a redundant defect is found by Test or Ops? Perhaps an assumption was wrong, the customer changed their mind, …etc.
- Think of how this effects the efficiency of the whole organization!
- Wait I thought it gained efficiency? Well…yes…locally! However its at the expense of destroying important feedback loops that cause defects to grow exponentially as batches are pushed through each functional silo.
- Lowers motivation and urgency
- Are you more likely to feel an urgency to deliver on day one of a two week sprint or on day one of a 100 day milestone? Me thinks two weeks. 🙂
- Which scenario would you feel more motivated by responsibility?
- If you are responsible for shepherding a capability from concept to consumption…oh lets say…something like a USER STORY.
- You were just capturing the requirements for a capability, but you knew several other groups would share in the responsibility to deliver it. (Arch, Dev, Test, Ops, …etc)
- Increased project slippage
- More uncertainty in process…means more uncertainty 😉
- Leads to Larger Batches
- Often called Death Spiraldevelopment. Here’s what the customer is thinking
- “If I’m not getting a capability for 6 months or a year I’m giving you everything I got! Prioritization…what’s that? Everything’s a P1!”
- Often called Death Spiraldevelopment. Here’s what the customer is thinking
- The entire batch is limited by its weakest link
- If 1 out of the 30 requirements in the batch has a security relevant change then we will treat the whole batch as a security relevant change.
- For those of us who have dealt with security relevant changes, we know this can be a huge pain and often leads to large delays.
Whoo! That was a mouth full. In the next post we’ll describe some practical steps you can take to reduce batch size so that you don’t have to deal with the stuff above. And I promise we will outline specific areas of your organization that will be involved to Reduce Batch Size!
