Little’s Law is Flawed. Break Free Now.
Introduction
In the dynamic world of software development, efficiency is paramount. Engineers and project managers often seek ways to optimize processes, enhance throughput, and reduce bottlenecks. One of the fundamental concepts aiding this pursuit is Little’s Law, a principle that originated in queuing theory but has found significant application in software development.
Little’s Law in a Nutshell
Little’s Law is a mathematical equation that establishes a relationship between three key parameters in a queuing system: the average number of items in the system (L), the average time an item spends in the system (W), and the average arrival rate of items (λ). Expressed as L = λ * W, it provides insights into the behavior of a system under varying workloads.
In the context of software development, these parameters are translated into the number of tasks in progress, the lead time for a task, and the arrival rate of new tasks. Little’s Law suggests that for a stable system, the number of tasks in progress is directly proportional to the lead time and the arrival rate.
It’s used extensively in backlog management and taught in management- and SAFe courses all over the world.
Traditional Application in Software Development
In the traditional application of Little’s Law in software development, teams aim to balance work in progress (WIP) with the arrival rate of new tasks. By doing so, they can optimize lead time, reduce bottlenecks, and enhance overall system efficiency. However, this approach comes with certain constraints, particularly in complex projects where the interdependence of tasks can create unforeseen challenges.
Breaking Free from Little’s Law Constraints
Software development teams are exploring innovative strategies to overcome the limitations of traditional Little’s Law applications. Two key approaches involve breaking down subsystems and actively managing the queue.
Breaking Down Subsystems
Complex software projects often consist of interconnected subsystems. By breaking down the system into smaller, more manageable parts, teams can focus on optimizing each subsystem independently. This modular approach allows for targeted improvements in efficiency, reducing the impact of dependencies and bottlenecks on the overall project timeline.
Removing subsystems from the equation leads to a cumulative effect in throughput. Even though this kind of work has no inherent customer value, actively working on eliminating as many of the dependencies within the system will pay off over the long run. It makes no sense from a queue-theory standpoint, but breaking down subsystems will help teams deliver value quicker in the long run.
This balance can be a difficult sell for a product manager. Delaying value to speed up value delivery over time is something nobody likes to explain to their stakeholders. But it’s something we do all the time anyway:
- Reworking code to be more resilient
- Upgrading frameworks to eliminate security risks
- Fixing structural problems to free up time for new features later
These things sound natural, and smart, to do. But in the context of Little’s Law, it’s clutter.
Actively Managing the Queue
Rather than relying solely on passive queue management, teams can take a proactive approach to prioritize and expedite tasks. This involves actively assessing the urgency and importance of each task, allowing for strategic allocation of resources to critical components. By actively managing the queue, teams can circumvent the rigidity imposed by Little’s Law and respond dynamically to changing project requirements.
Experimentation in the context of Little’s Law is a bad thing. It’s just another task that enters the closed system, taking up space without a definitive result. But when we use experimentation to actively manage -or reduce- the queue, we’re breaking free from the closed system. We’re now operating in a live system, where the law quickly breaks down.
We need to be able to think about ‘work item superposition’, where an item is pending in the queue depending on an experiment. It can then leave the queue again with a minimal amount of work being done.
Conclusion
Little’s Law has proven to be a valuable tool in understanding and optimizing queuing systems, including those in software development. However, recognizing its limitations, forward-thinking teams are breaking away from the traditional application by embracing strategies such as breaking down subsystems and actively managing the queue. By doing so, they can navigate the complexities of modern software projects, enhance flexibility, and ultimately deliver more efficient and timely outcomes.
We need to be focused on finding the best strategy to optimize within the queue instead of limiting the amount of work that enters it. When you see your software development process as it is, an open system with free movement of work items, you’ll understand why Little’s Law is counterintuitive.
Thanks for reading my blog. If you have thoughts on it, I’d love to hear from you in the comments or in a direct message. Liking and sharing the article is highly appreciated! I write about agility, software development, change in organizations, team dynamics, careers, and my observations in over ten years of (product) management. Follow me if you’re into that sort of stuff.
If you are not a member of Medium yet, you can use this link to become one and support me, and all other Medium writers, directly. Visit Scrum-Store for all your Scrum-related apparel!
