Limit, to Win It - How putting limits on your team will allow them to do more

Kent Norman
Manager, Houston Office

I am the manager of an application development team and I love to deliver solutions to clients. Delivering means making a list of commitments and then successfully following through with them. Over the course of my career, I have seen otherwise successful individuals and teams take on more work than they can deliver, in order to please their boss or client. Taking on this additional work actually reduces their ability to successfully deliver and results in disappointing the boss or client. The following story highlights this phenomenon.

A development team starts a new project and has a small amount of initial success building out a feature. As stakeholders begin to see the success of the project, each stakeholder asks for new features, all of which are roughly the same amount of work as the original feature. The development team manager, thinking his team is mature enough to handle additional work, agrees to start working on multiple features at once. The manager knows the power and influence that the stakeholders wield in the organization and wants to show each stakeholder that progress is being made towards their wishes.

Soon the development team has nearly as many features in development as there are developers on the team. As time passes, the manager cannot figure out why the development team consistently misses estimates and milestones. Delivery dates continue to be pushed back until concessions are made on quality and developers are asked to work nights and weekends. After a few months, multiple team members have moved on to new career opportunities because of the working conditions and the product is in such bad shape that it is nearly impossible to maintain.

Queueing Theory and Lean Development

In order to help us understand what mistakes were made by the development team, I am going to introduce some basic queueing theory and lean manufacturing principles. The first principle is known as Little’s Law:

The average number of work items in a stable system is equal to their average completion rate, multiplied by their average time in the system

In simple business terms that means:

The amount of time it takes to get an idea from someone’s head to the market is a function of the number of tasks you are working on at once and how long it takes you to do complete each task. Seems simple … right? If so, why do so many enterprises fail to understand the implications that this theory has on delivering products to market?

In order to help us understand how Little’s Law can be applied to developing software, let’s look at a typical software development life cycle using queuing theory and Little’s Law terminology. The amount of time between an item entering a system and its completion is known as Lead Time in lean manufacturing. In agile software development, new ideas enter the system as user stories from a product owner. Over time a list of features is created in the form of a backlog (we can think of this as a queue). It is the job of the product owner to prioritize this work with the development team. The development team will then agree to work on a set amount of work over a given time (usually a sprint – 2-3 weeks).

KNorman1

The amount of time spent on completing a task is known as Cycle Time. Assuming you are able to complete a task in one day, your cycle time would be one day for the task. So, if you were to complete a user story (group of tasks) in a sprint, your cycle time for the user story may be 2 weeks (the time the user story was worked on during the sprint) but your lead time could be 3 months (the amount of time the user story waited in the backlog + the time the user story was being actively developed). What business tends to care about is lead time as reducing the amount of time from idea to final product drives time to market.

Delivering Value

Value can only be realized when the idea has been turned into a product that is in the end user’s hands. As such, reducing the amount of time it takes to go from idea to reality helps to drive business value. In terms of Little’s Law, we want as small an Average Lead Time as possible to increase throughput. Little’s Law expressed as a formula is:

Average Lead Time = WIP (Work in Progress) * Average Cycle Time.

If my development team works on 5 different features and it takes an average of 4 weeks to complete a feature, then my Average Lead Time is 20 weeks. I must be able to plan 20 weeks in advance to effectively give estimates to my stakeholders.

KNorman2

However, if instead of working on 5 different features my development team only works one feature at a time my average lead time is reduced to 4 weeks because I have limited my WIP to 1. As a project manager, I have a higher degree of confidence of being able to accurately estimate 4 weeks of work than I do 20 weeks of work. With the increased confidence comes reduced risk and more predictability. All of this results in the development team being able to accurately communicate with the business when features will be finished.

KNorman3

Reducing WIP also delivers value to the customer because it results in delivering features quicker. Rather than waiting for 20 weeks for all the features, the business wants; the business will be able to receive the most important feature in 4 weeks. This also allows the business to gather feedback from the customer faster to better prioritize future releases. Information gathered from one release will be able to be used as input for subsequent releases.

Costs of Context Switching

Based on the story above some of you might be thinking “The only advantage of limiting WIP is delivering small chunks of work sooner. It will still take 20 weeks to complete 5 features if each feature takes 4 weeks to develop”. While delivering small chunks of work sooner is important to gather feedback, limiting WIP does more than that because it reduces the costs of context switching.

Let’s think about how cars get manufactured. In most cases, each model has its own production line or set of steps that are completed to construct the vehicle. The production line for pickup truck probably looks very different than of a roadster. Whenever production for the pickup starts the manufacturing floor is configured in a set of stations that are optimized for building the pickup. When production for the roadster starts the production for the pickup stops and the stations on the production floor are rearranged in order to be optimized for the roadster. This switching of production setup from the pickup truck to the roadster results in downtime for the production line.

In development terms, we can think of the pickup truck and the roadster as features in a product. Each feature requires its own production line and associated cost for setting up the production line. While you would never see a roadster and a pickup truck being constructed on the same production line you will find the software development equivalent occurring in many organizations as two unrelated features are being developed at the same time by the same team. Imagine working in the car plant manufacturing line and you just finish at your station working on a truck and the roadster comes down the line for you to work on. While you may be skilled to perform the task, you will probably have to go find the right tools and plans required to complete the work on the roadster.

In the same way that limiting the production line to a single model increase the throughput of car construction, limiting WIP in software development to a single feature per team increase throughput by eliminating the costs of context switching. Going back to the earlier example of five features each taking four weeks to complete for a 20-week total. While one feature might take four weeks to develop in isolation, that same feature might take 50% longer if worked on concurrently with another feature because of the cost of context switching.

WIP at Scale

At the end of the day, what I love about limiting work in progress is that it scales up and down. Limiting WIP can scale down to individuals who can apply this theory to limit the number of tasks they are working on at once, and limiting WIP can be scaled up all the way to C-level executives who are deciding the number of initiatives the company will be focused on for the next year. By limiting the amount of work we do at once we increase our throughput and the amount of work we can accomplish. So, in conclusion, if you really want to get more done, try doing less.

*Kent Norman originally shared this post on his LinkedIn.

More Perspectives

Perspective
by Bruce Ballengee
Teaching Roots Run Deep
Perspective
by Kent Norman and Kevin Moormann
I’ll be Home in Five Story-points
Perspective
By Russell Clarkson
Is your Ecosystem a pipeline or a platform?
Perspective
by Dimitrios Vilaetis
Business Capabilities: a Spotlight for Strategic Decision Making
Perspective
by Russell Clarkson
Mark Your Exits
Perspective
by Bruce Ballengee
Leadership and Company Culture
Perspective
by Kerry Stover
I Know You Believe You Understood What You Think I Said
Perspective
by Brian Duperrouzel
How to Handle Management Kidnapping
Perspective
By Russell Clarkson
What Chuck Yeager Taught Me About Disruption
Perspective
by Brian Duperrouzel
Lessons on Project and Team Management
Perspective
by Bruce Ballengee
Consulting that Focuses on the Individual
Perspective
By Bruce Ballengee
Developing the Individual
Perspective
by Lori Dipprey
Why Performance Reviews are Here to Stay at Pariveda
Perspective
By Nathan Hanks
What it Means to be "in the People Business"
Perspective
By Bruce Ballengee
Pariveda Fin-Centric Design
Perspective
By Bruce Ballengee
Unleashing the Power of Humility
Perspective
By Mike Strange
4 Reasons to Leverage the Power of Small Teams
Perspective
By David Watson
The Benefits of Working in Teams
Perspective
by Sean McCall
Forget Coffee- Energize Your Work Morning
Perspective
By Allison Esenkova
Wearing Heels to the Top
Perspective
by David Watson
Work-Life Balance
Perspective
by Allison Esenkova
Listen to the Still Small Voice
Perspective
By Kerry Stover
Must Read Books from the COO
Perspective
By Russell Clarkson
Why You Should take a Massive Open Online Course
Perspective
By Scott Hajer
The Importance of Making Space to Think
Perspective
by Sean McCall
4 Ways Sports Can Benefit Careers
Perspective
By Russell Clarkson
Stand Up for Good Presentations
Perspective
by Derrick Bowen
How Much of your Project Value is At Risk Due to Cognitive Bias
Perspective
by Susan Paul
Capabilities as Building Blocks
Perspective
By Susan Paul
When Corporate Culture Undermines IT Success
Perspective
by Kent Norman
Limit, to Win It
Perspective
By Brian Duperrouzel
The Case for Onshore Technology Teams
Perspective
By Tim Hurst
Unlocking Marketing ROI Analytics
Perspective
by Brian Duperrouzel
Hippos and Cows are Stopping Your Machine Learning Projects
Perspective
By Jack Warner
Building Smart Deployment Pipeline
Perspective
By Tom Cunningham
The Sound of the Future
Perspective
By Scott Hajer
You Need Only One Kind of Recruiting Technology
Point of View
by Ansley Galjour
Continuous Brand Engagement
Perspective
By Marc Helberg
3 Ways You Can Begin to Take Patient Experience More Seriously
Perspective
By Ryan Gross
What Does It Really Mean to Operationalize a Predictive Model
Perspective
by Sophie Zugnoni
Did You Catch Machine Learning Fever?
Perspective
By Collins DeLoach
What does Cloud Transformation mean it IT?
Perspective
By Mike Strange
Untangling and Understanding DevOps
Perspective
by Clayton Rothschild
Blockchain in an Enterprise Setting
Perspective
by Mike Strange
DevOps a Practical Framework for Technology Process and Organizational Change
Perspective
by Julio Santos - Finity Member
Context as Currency
Perspective
by Oussama Housini
Why DevOps?
Perspective
by Dave Winterhalter
Data in the Dugout
Perspective
by Brian Duperrouzell
3 Tips to get the Blockchain Ball Rolling
Perspective
by Victor Diaz
6 Things to Consider when Choosing a Data Visualization Library
Perspective
By Julio Santos and Jon Landers
How Customer Context and Smarter Algorithms will Power the Next Level of Experiences and Engagement
Perspective
by Mike Strange
Can We Predict the Future?
Perspective
By Brian Duperrouzel
No Estimates, No Approval, No Dice
Perspective
By Marc Helberg
How AI Will Affect Your Patient’s Experience
Perspective
By Sean Beard and Brian Orrell
Life After Mobile
Perspective
by Phillip Manwaring
Let Serverless Solve the Tech Problems You Don't Have
Perspective
by Mike Strange
Bigger is Not Necessarily Better
Perspective
By Marc Helberg
Patient Experience – Taking the Next Step Through Machine Learning
Load More