Demand and Capacity – The Laws of Physics Must Apply

Balancing Demand and Capacity

At some point in my career, I discovered that having an aggressive “can do” approach leads to much better outcomes for both my team and myself in business settings. It can be hard work ignoring my inner cautious engineer in order to embrace a more aggressive “let’s give it a go” attitude. However, it is clear to me that this mindset has been a significant positive in my engineering career, and it is something I try to coach to every engineer I work with. However, there is a challenge with this approach: How do you know when you are going too far or taking on too much? The answer to these questions requires you to develop an understanding of demand and capacity within your group.

Organisations often apply wishful thinking to their delivery processes. The simplistic thinking goes, “Let’s do more so that we can deliver more.” To counter this wishful thinking and my own learned desire to be aggressive, people who work with me frequently hear me say, “the laws of physics must apply.” This is a simple reminder to myself that while we can be aggressive, there is only so much we can do at any point in time. This is true because we are always operating with the finite capacity of our team. Even if your development team magically doubled in size, you would have more capacity, but it would still be finite.

In my previous article, When Engineering is a Black Box, I discussed the importance of making the team’s workload (Demand) fully visible to the entire organisation. What I touched on but didn’t fully explore is the fact that demands only become a problem when they exceed the capacity of the team. Demand and capacity, when out of balance, can have a significant detrimental impact on delivery. In this article, I want to explain how it happens, what it looks like, and offer some guidance for avoiding this problem.

The Impact of Exceeding Capacity

When demand exceeds capacity, the team becomes overloaded. This leads to slower delivery times, increased errors, and ultimately, a demotivated team. One crucial concept to understand here is Little’s Law, which states that the average number of items in a queuing system (L) is equal to the average arrival rate of items (λ) times the average time an item spends in the system (W), expressed as:

L=λ×W

In the context of software development, this means that if you have an increasing arrival rate (λ) of work items (L) in a team with stable capacity, then the average time to complete each item (W) increases. Excessive demand on a system’s capacity results in increased cycle times and delays, reducing overall efficiency and throughput. This leads to a bottleneck effect where work items pile up, exacerbating delays and creating a vicious cycle of inefficiency. 

Introduced in the 1950’s, Little’s Law has been peer reviewed and proven beyond doubt. It is verified science. Therefore, the effects of overloading your system are pre-determined and inescapable. No amount of wishful thinking will help you avoid the consequences.

What Does It Look Like

In When Engineering is a Black Box, I shared real-world data highlighting an organisation grappling with an average of 150 work items per week. At first glance, this might not seem problematic. However, with a finite capacity of 30 people in engineering, it meant each individual had an average of 5 work items on their desk at any given time, leading to an overloaded team. While the Work In Progress (WIP) graphs in Figure 1. show workload, we can see the impact of this workload on the teams capacity, as predicted by Little’s Law, with some additional flow data.

The work in the WIP graphs was undertaken over a 7-week period. As shown in Figure 2. this work had a flow efficiency score of 41%. This means that, of the 287 work items completed, on average they spent only 41% of their cycle time being actively worked on. The other 59% of the time was spent waiting for someone to work on the item. Essentially, for almost two-thirds of the time required to complete each work item, nothing was happening. In Lean management terms, this delivery system was experiencing 59% waste.

With 59% waste, it might be tempting to think that the team was not working hard enough or lacking in ability. However, this was not the case. The team was highly talented and everyone was constantly busy. The real issue was the excessive workload relative to the team’s capacity. Let me give an example of how this waste can occur in an overloaded system.

How Does Waste Occur?

In this particular organisation, the development process was split into three main phases: Development, Code Review, and Testing. During the code review phase, once coding was complete, a senior developer not involved in the development of the code had to perform the review. This dependency meant that code could wait for days to be reviewed, as all senior developers were busy with other tasks. Effectively, the code was siting in a queue waiting to be reviewed. Little’s Law states that the more work you add to a stable system, the more queueing will occur in that system. This becomes particularly visible when we break down the flow efficiency score into its constituent components, as shown in Figure 3. On average, work waited for code review 17% of its total cycle time.

The team members were so surprised by these numbers that they immediately struggled to accept the accuracy of the data presented. This is a very common reaction because, from the team’s perspective, everyone was extremely busy all the time. This reaction highlights a traditional project management mindset often applied in organizations: we tend to think in terms of people or resources. From a resource viewpoint, the system seemed to achieve nearly 100% efficiency by keeping everybody busy all the time.

However, from a work delivery perspective, considering features, bug fixes, security risks, etc., the system was only achieving 41% efficiency. Customers pay for the delivery of value, not for ensuring the team is working hard. Moving work efficiently through our delivery system rather than keeping people busy should be our primary objective in the delivery game.

What did they do next?

The importance of visibility cannot be overstated. Before generating the flow data above, the organisation was unaware of the level of waste in its delivery system due to excessive demand relative to finite capacity. Having visibility offered significant insights into the bottlenecks in the delivery system. With this data in hand, the organisation set about reducing waste by adopting new development guidelines:

1. Manage Workload: On average, an individual should have a maximum of three work items, ideally only two. This is not quite a WIP limit but a good start in managing organisational workload. To be reviewed and assessed over time with fresh data.
2. Expand Code Review Participation: There was a serious conversation about the code review practice and if the return was worth the investment of 23% of cycle time. There was acceptance that this was excessive but also a belief in the value of the practice. Therefore, all engineers now participate in code reviews, not just senior developers. The team redefined the purpose of code reviews and established clear guidelines that were shared with the entire engineering organisation.
3. Reduce Dependencies: Improve cross-functional capabilities within teams to decrease dependencies. This was a major contributor to the high percentage score in the “Test Ready” lane. While recognising that there were significant cultural issues that needed to be addressed to make this possible and that this would take time, this step was deemed necessary for long-term improvement.

By implementing these guidelines, the organisation aimed to balance demand with capacity, thereby reducing waste and improving overall efficiency and throughput.

What to Look Out For in Your Organisation

Excessive demand often occurs due to several factors:

• Poor Visibility: Lack of clear understanding of the current workload and the team’s capacity. This is the core issue.
• Wishful Thinking: The belief that simply pushing for more work will result in more output. Acting like capacity is infinite.
• External Pressures: Stakeholders pushing for more features without considering the team’s limits. This is usually caused by Poor Visibility, Wishful Thinking or both. 

Avoiding the Problem 

• 1. Visibility: Make all work visible to both the team and stakeholders. Use tools and metrics to track current workload and capacity.
• 2. Prioritisation: Be ruthless in prioritizing work. Focus on what is truly critical and be willing to push back on less important tasks.
• 3. Communication: Ensure ongoing communication between the team and stakeholders. Regularly update stakeholders on progress and capacity constraints. Do this using business language (see Engineering Leaderships Biggest Challenge).

By understanding and balancing demand and capacity, you can maintain an aggressive approach while avoiding the pitfalls of overloading your team. This balance is key to sustainable success and ensuring that the team can continue to deliver high-quality work effectively.

Conclusion

With software development, it is Little’s Law rather than the Laws of Physics that are most relevant. However, you will never have a team with infinite capacity – not in this universe anyway. So, as a simple, tongue-in-check mnemonic, remember that when it comes to demand and capacity, the laws of physics must apply.