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

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

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.

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.

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.