How to Ruin a Software Development Organization by Focusing on Throughput

September 10, 2016 — Posted by Guy Beaver

“We’re good at saying yes.”  --Feedback from an overloaded organization challenged with prioritization. 

In today’s overloaded world, you aren’t effectively saying “yes” to anything unless you say “no” to something else.

In knowledge work, especially software development, the capacity of an organization to deliver solutions is very abstract and difficult to quantify.  Since knowledge requests aren’t really tangible (they are abstractions of desired functionality), it is difficult to see the impact of adding a feature request to a list of requirements, or adding another project to a portfolio of projects.   

Let’s look at the often-used example of highway traffic.  Picture a mile-long stretch of Interstate with three lanes of traffic.  At the end of the one-mile stretch, we put up cones and reduce the lanes from three to two. You’ll soon notice you can fit a LOT of parked cars on that stretch, and that represents our fixed capacity (maximum number of cars that can fit). 

Maximize Capacity Utilization...?

Maximize Capacity Utilization...?

But notice if we measure the number of cars reaching a point past the merge zone over time, we’ll get a reasonable throughput measured by cars per minute.

Now let’s start a simulation where we gradually let cars enter the empty highway.  Early on we are in a phase where the throughput (cars per minute) increases for every car added.  If the cars are limited by law to 60 mph, then the average waiting time for each car on the mile stretch is one minute.  This falsely leads us to believe that we can always add more and more cars and get more and more throughput (cars per minute) across our stretch of highway, which is true…for a while.

...or Minimize Waiting Time?

…or Minimize Waiting Time?

HOWEVER, way before we reach 100% capacity of cars that can fit on the mile-long stretch, the throughput stops increasing, and what’s worse, the average waiting time starts to increase, but the throughput just past the bottleneck is still high!  You’ve been there—the phantom event somewhere up ahead makes you come to a screeching halt and the dreaded, stressful traffic jam emerges in front of you for no apparent reason.

This is also the fallacy of focusing on throughput.  We can be fooled by a high throughput number at the expense of waiting time.  This is very important—once we approach the capacity limit of the highway, the wait time for any new car entering the highway INCREASES.

What does this have to do with knowledge work and capacity?

We tend to treat knowledge work capacity like an uncrowded highway, where we can add a car, increase throughput, and not impact waiting time.

The Lean value stream is our “knowledge work interstate.” Its purpose is to bring visibility to the work required to get from initial idea to a solution consumed by the customer.  

Now consider two software delivery organizations.  One bundles up feature requests into annual projects that deliver 60 features at the end of the year.  Another organization can deliver with the same annual throughput, but does it in batches of 5 per month.  Both have the same annual throughput of 60 features per year, but which is better?  

No matter how valuable any individual feature request is in the first organization, the soonest it can get through the system is one year.  The second organization could feasibly get any feature request done in a month from the time it was requested.  YET BOTH HAVE THE SAME ANNUAL THROUGHPUT.

Lean thinking guides us to view the value stream from the customer’s perspective, with a premium being placed on how long the customer waits from the time of the original request.  Managing queues and not overloading knowledge work capacity helps flow and wait time.

Instead of focusing on throughput, the right question to ask is what is the highest business value that can be delivered in the least amount of time.  This simple change in perspective is to see the true measure of productivity, which is the time required to get any one request through the system.

So what are the key lessons and how do you apply them in your shop?

1.    Measure and make visible the time it takes for any high-valued consumable feature to be developed in your organization.  Focus your shop on driving down this wait time.

2.    Create and make visible to the entire organization the sequenced priority of work, AND FOCUS ALL EFFORTS ON COMPLETING WORK IN THAT ORDER!

3.    Minimize the number of work items open (at all levels) to minimize wait time and maximize value delivered.   

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Guy Beaver

Guy Beaver was VP of Enterprise Engagements and a Senior Consultant. He is a seasoned technology executive known for building Lean organizations that are driven by business priorities. With 30+ years experience in Financial Services, Aerospace, Health Care and eCommerce, his technology accomplishments include managing enterprise web development and delivery for world class transaction systems (16 Million users), large data center transitions, and SaaS operational excellence utilizing Lean IT practices. He is skilled at organizational change and is the co-author of Lean-Agile Software Development: Achieving Enterprise Agility.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban