For software, delivering value quickly requires the fast and smooth flow of work from development to operations. In this video, we discussed the importance of batch size, which is critical to limiting the amount of work in progress in ensuring the smooth flow of work from development to production. The book, Lean Thinking: Banish Waste and Create Wealth in Your Corporation, illustrates the differences between large and small batch sizes using a mailing simulation. The simulation has four steps: folding the paper, inserting the paper into an envelope, sealing the envelope, and stamping the envelope. With a large batch size, in other words, mass production, each of the aforementioned operations is performed sequentially. That is, we fold all the letters, insert all the letters into envelopes, seal the envelopes, etc. If each operation requires 10 seconds, then the entire process requires 120 seconds for three letters, and the first letter isn't ready for 100 seconds. With a small batch size, in other words, single piece flow, each operation is performed sequentially. That is, we fold the first letter, insert that letter into an envelope, seal that envelope, etc., and start the process again with a second letter. If each operation requires 10 seconds, then the entire process still requires 120 seconds for three letters, but the first letter is ready after 40 seconds. Now you might be thinking, who cares? The entire process takes the same amount of time and we've clearly ignored changeover cost. For example, most of us can fold three letters, one immediately after the other, faster than folding three letters with breaks in-between. Yet clearly there's an advantage to the small batch size when we see our letter courier down the street. If the letter courier reaches our house in 90 seconds, then we have two envelopes ready when using a small batch size, whereas none of the envelopes are ready when using the larger batch size. This delay could be significant. For example, we might incur a late penalty if the letters include payments for bills that are due. In addition, consider what happens with a large batch size if we realize when we attempt to seal the first envelope that the letter doesn't fit. Instead of folding it in thirds, we accidentally folded it in half. Now we must take all the letters out of their envelopes, unfold them, and start the entire process from scratch, having lost more than 60 seconds. In comparison, if we make the same mistake with a small batch size, we'll detect it after only 20 seconds, and there's only one letter that must be corrected. In practice, these benefits are much more significant because the effects compound as batch size increases. A batch size of three, which fits nicely on this slide, isn't particularly large. Small batch sizes reduce work in progress, decrease lead times, promote faster detection of errors and less in rework. These same issues apply to technology. Consider what happens when we have an annual software release with an entire year's worth of changes being deployed to production. This massive batch size, all the changes from developers from the past 12 months is the antithesis of smooth flow. All downstream work centers, particularly IT operations, but also quality assurance and information security, must attempt to cope with the surge in demand. It's no different than folding hundreds of thousands of letters at once. When all those letters arrive at the next work center to be inserted into envelopes, that work center's work in progress skyrockets, which unduly delays other mailings that require the same resources. Moreover, the more complex the changes, the more difficult it is to diagnose and to remediate failures. It's no wonder that such release cycles are stressful. What we should do instead is continuous delivery, where each change is integrated, tested, and deployed independently as soon as it is complete. Continuous delivery is the realization of single piece flow for software development.