Little's Law is an equation that states: Lead Time equals Work in Progress divided by throughput. The equation suggests that if you increase the throughput or reduce the work in progress, then you will reduce the lead time. This paper explores how these concepts relate to DevOps and provides an example of how they could be applied.

Lead time

Lead time is the time between initiating and delivering a work item.
Assuming initiation happens when a story is added to the sprint. Delivery, on the other hand, could be clearer. Delivery could mean the point when the story is marked as done or closed. However, that status does not always mean that its been delivered to the customer - or deployed to production.

Let's assume an average lead time is six days. Perhaps just two of those days are spent coding and researching, 1 day is spent testing and getting code reviews, and the remaining three days are usually awaiting a production deployment window.

The first three days of "WIP" could be highly automated and collaborated on by the team, running thousands of tests and moving code between 4-5 separate cloud computing environments. In other words, if these 3 days could be taken down to a few hours if:

1. Cloud computing environments, and cloud resources, should be available on demand for developers. A developer should be able to dive into the code within minutes, meaning that whatever this very-early lifecycle stage is called, the number of seconds it takes for IDE to boot up is part of this time.
2. Kanban is used, and the deployment process is part of the flow. Better yet, the releases being deployed should be associated with specific stories, ideas, or bugs that were for making this release ready for deployment to the customer.

Cycle Time

Cycle time is the time between two successive deliveries. Our final bottleneck is deploying into higher environments, not owned by the product team but by a cloud services team. The CS team generally needs advance notice of at least 3 days to do a production deployment. Several closed stories, in the form of releases that have gone through 5 lifecycle stages of testing, are all sitting and waiting.

Throughput

Throughput is the rate at which items are passing through the system. The throughput could be drastically increased when the whole process is automated and the release ready to be deployed to production after going through automated tests, code reviews, and UATs. Plus, the time between releases would be cut if the product team had control over the production deployment environments and could deploy more often. This way, the releases wouldn't need to be bundled in a sprint and wait for a production deployment window every two weeks.

Work In Progress (WIP)

WIP Work in progress; the number of work items in the system. Work that has been started but not yet completed.

Whether the time spent waiting for a release is counted as part of WIP depends on what you're trying to accomplish. In a truly CI/CD culture, WIP should most definitely include, if not track, time spent in each release lifecycle/environment.

Most importantly, once it passes all the tests if it's not being sent to production, it's losing value.

Epics

One could almost consider these releases batches to be a more logical way of grouping stories together than an epic. Rather than keeping them neat and in different epics, they could all be organized by story type or even by tickets. A release can have stories, bugs, and improvements that could stretch through several sprints.

Sprints

If we release every sprint, is all the code done in a sprint get deployed in the "sprint release"? Not very practical; there are certain things that take more than two weeks to get ready to be reviewed and tested by other people (Dev -> UAT). One option is breaking working software into chunks and releasing working early versions of it, then moving back and forth from Dev and UAT to find and fix bugs quickly.

Leading by the Little's Law

When applying Little's Law to DevOps, the idea is to minimize the lead time and shorten the cycle time by automating the process, making sure the WIP is not too high, and breaking stories into smaller chunks that can be quickly reviewed, tested, and deployed. This will ensure that working software is released as often as possible and that it is not unnecessarily waiting for its turn in the release window.

The goal of applying Little's Law is to reduce both the lead and cycle time to a minimum by optimizing the system to reduce the amount of WIP and automating whatever process can be automated.

Additional Elements to Explore

In this discussion, a few elements could be explored further for a deeper understanding of applying Little's Law in a DevOps context:

• Continuous Integration and Continuous Deployment (CI/CD): Although mentioned briefly, diving into how CI/CD pipelines and practices can help support the application of Little's Law would provide more context and guidance. CI/CD can help automate the deployment process, decreasing lead and cycle times.
• Collaboration between development and operations teams: One of the core tenets of DevOps is fostering collaboration between development and operations teams. This aspect could be further explored, relating it to how a more collaborative environment can help reduce lead time and WIP while increasing throughput.
• Monitoring and feedback loops: The importance of monitoring, feedback loops, and incorporating lessons learned is another crucial aspect of DevOps. Regularly reviewing the processes and pipeline to identify bottlenecks and potential improvements helps support continuous improvement and further reduce lead and cycle times.
• Scaling DevOps practices: As organizations grow and evolve, so do their development and operational needs. Discussing how to scale DevOps practices while maintaining the speed and agility that Little's Law encourages would provide valuable insights.
• Tools for implementing continuous improvement: Identifying and discussing industry-standard tools and technologies that support implementing Little's Law in the DevOps context can help bridge the gap between theory and practical application.

Conclusion

The main takeaway from this discussion is that Little's Law applies to DevOps and encourages an agile approach to deploying working software. Reducing the lead time by automating the testing process and pushing working software as regularly as possible.

It's difficult to deliver working software, so it is important to stay ahead of the curve by breaking down complex tasks into simple components that can be quickly and regularly deployed into production.