When most people think about DevOps, Continuous Integration (CI), or Continuous Deployment (CD) they think about tools like Jenkins or Bamboo. And, indeed, these tools are indispensable for rapidly moving software through the development pipeline. However, an even more rudimentary principle is required to truly enjoy the benefits of any CI/CD environment – limiting work in progress (WIP). Work in progress is the number of items that are currently being developed. The higher the number, the more difficult and time consuming deployments become. And, conversely, the lower of number of features in development, the lower the risk for the deployment and the more rapidly it can be deployed to live systems. Limiting the WIP to a small number – a single new feature or a couple of important bug fixes – ensures that you can get the changes tested and deployed in short order. This goes well with the ideals of agile development – quick sprints where a small number of items are completed – and ensures that focus is kept on the most important items. Once that sprint is complete, a new version can be pushed to end users. This ensures users have want they want, turnaround time is low, and bugs are kept to a minimum as changes are small and easily tested. This principle applies well beyond software. In fact, it was originally documented on factory floors. Creating products in small batches ensures that if there is a problem, it’s limited to a small batch and that the first shippable products are available more quickly than large batch processing. How does your company handle work in progress? A small number of items, or huge batches? Does it take forever to release a new version or to have a product ready to market? Consider the impact of limiting the work in progress to a small number and frequently releasing your software or product and how it could impact your time-to-market and ultimately increase revenue!