Skip to main content

It’s All Relative

Reading: It’s All Relative

smaller batch sizes

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!

Output v Outcomes

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 ….

Least Valuable

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
Next Online Coding Environments

Leave a comment

Your email address will not be published. Required fields are marked *