Smaller Batch Sizes: It’s All Relative

Written By Jim Hayden

Often when working with clients I am asked about smaller batch sizes…mostly in the context of “How is that even possible? Look at what’s on our plate already.”

Admittedly that’s a tall order. Everyone is working as hard as they can; unfortunately, nothing is fundamentally moving through the system. Typically the result at end of the quarter is that most, if not all, the myriad of commitments end up delayed significantly or outright missed.

There are plenty of apparently valid “reasons”for this being the case. To put it politely the delivery teams are in a constant reactive mode not responsive …reacting to who happens to be complaining the loudest or can escalate to the most senior executive.

Frustrating for the teams and certainly annoying for the stakeholders who are depending on the work to be completed. Consequently there is more pressure to double down and start work earlier. “Better start now or they will NEVER get it done”. The result being too much Work in Process (WIP).

Everyone is “crowding the turnstile” at once!

A couple weeks ago I heard one of my fellow LeadingAgile consultants say something that really resonated with me. He talked about the difference between “output” and “outcome”. We should be more concerned about the latter than the former.

Certainly we have to produce “output” to generate “outcomes”. But while we’re at it why not do both?

“Learn to produce output consistently that produces the best chance of achieving your desired “outcomes”.

So how do you become “more consistent” when the engine is “clogged”? How do you pragmatically compare value when it’s hard to articulate?

The “System of Delivery” (ie the ability of the organization to turn the “ask” into “working tested software) needs to be predictable…that means it needs to get unclogged. Second, more often than not the “ask” is greater than the SoD capacity we could choose to limit ourselves to working on the highest value things.

Obvious? Yes. Easy to do? Well…….

Here’s the reality. It IS actually pretty easy to do if you’re willing to take the time and engage in this vital, yet often ignored conversation.

The Challenge

Here is the challenge… the team has multiple requesters vying for a constrained capacity (I’ll choose to limit this discussion to this situation….most organizations don’t have unlimited money, time or resources). Every “ask” is “valuable” from the requester’s standpoint. Oftentimes the “ask” is articulated in the form of a WHAT (and maybe a HOW as well). Buried in the request is a hypothetical OUTCOME that will result from the requested “ask” (output).

The conversation that needs to be had should address these two fundamental questions:

  1. How valuable are these requests in relation to each other?
  2. Which of these are most likely to drive the desired valuable OUTCOME?

Without going into the details let me walk you through how a recent client conversation resulted in “unclogging” the engine”. The “how to do this” will be the subject of a future blog post from my friend.

The “ask” to the team when teased apart turned out to be 100+ “valuable” items. These were sorted into three buckets: Valuable, High Value and Highest Value with a “no more than” constraint place on the two highest value buckets.

The result looked something like this:

Setting aside the lower two buckets the Highest Value items were arranged left to right with the highest of the high on the left and the lowest on the right. When finished the result looked like this:

When asked to qualitatively “size” the value a distribution emerged that spanned from 100 to 1 looking something like this:

When the team’s capacity was considered and applied starting on the left they found that they ran out of capacity quickly. In fact, they could only realistically commit to only a portion of the Highest Value bucket! They couldn’t even touch the other two buckets!

Here is the “Ah Hah!” moment ….

The “1”on THIS list is by definition individually more valuable than ANY individual item in the other two buckets! If we drew the value graphically like a Pareto chart it might look like this:

The VAST amount of the value is contained in a very small portion of the “ask”!

Why then are we wasting time and effort even discussing these items let alone putting effort into them at this moment?

This is a very powerful technique to unclog the engine! All the (relatively) lower value items are a distraction and taking needed focus away from delivering the higher value items.

This process resulted in …

  1. A renegotiated commitment in light of the shared understanding of (outcome-focused) valuerelative to the current capacity (the buckets and order being vetted by the Product Owner and keystakeholders).
  2. The means to evaluate what would be the impact if additional capacity/resources were madeavailable
  3. A prioritized backlog of items to pull thru the System of Delivery
  4. A technique on how to slot new requests against pending items in the backlog when emerging requests arise

About the Author:

Jim Hayden brings over 25 years of leadership experience pragmatically solving complex problems and delivering tangible, bottom line results. The discipline, teamwork, communication, coordination and ability to “observe and adapt” flying fighter aircraft in the US Air Force are the foundation of what he brings to businesses today. Since leaving the military Jim has dedicated his time to leading and motivating tech-savvy teams in delivering business-critical technology solutions…Read More.

Originally published at www.leadingagile.com on June 11, 2018.

--

--

--

The latest thinking from the field as we guide our clients through agile transformation.

Recommended from Medium

Remembering Binary Search

EthSign Community January Update

Meaningful Docker image tags made with build tools

Day in the Life of a Gusto Engineer: New Grad Edition

GitHub Notifications: Cut through the Noise

Post-mortem on the GVA staking bug

Beginners Tutorial: Set up a Linux Virtual Machine on Cloud

C++20 Concurrency: part-3 request_stop and stop_token for std::jthread

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
LeadingAgile

LeadingAgile

The Path to Agile Transformation Starts Here | www.leadingagile.com

More from Medium

What Can Business People Learn from Developers That Work in Agile Teams?

How silos wreak havoc and block your outcome dreams

Make Your Scrum Team More Effective With Management Support

Agile | Adapt Digest