In this module, we've already discussed a few myths surrounding DevOps principles. Another myth I want to address is that having a lot of work in process is the best way to get more done, this simply isn't true, and we're going to discuss why in this video. After watching this video, you'll be able to discuss why setting work-in-process limits, together with adequate feedback. Loops can be an effective strategy for increasing productivity throughput. You'll also be able to describe the five thieves of time one of which includes too much work-in-process, and we'll wrap up by discussing some of the challenges from stakeholders and others in setting work-in-process limits. The use of work-in-process limits more commonly called WIP limits. To manage the flow of work is well known in the lean community. When used effectively properly, set WIP limits drive process improvement, increase throughput, and makes constraints visible in the system. What's interesting is that WIP limits alone do not strongly predict delivery performance, it's only when they're combined with the use of visual displays and have a feedback loop from production monitoring tools back to dev teams or the business that are strong effect seen. When the teams use these tools together, a much stronger positive effect on software delivery performance is seen. DOMINICA DeGRANDIS is considered the foremost authority on effective Kanban workflow and in her book, "Making Work Visible," she describes what she calls the five thieves of time. Thief number one is too much work in process. The other four thieves of time are conflicting priorities, unknown dependencies, unplanned work, and neglected work, all exacerbated the too much work-in-process problem if you think about it. Too many conflicting priorities lead to worker overload which can easily lead to employees taking on, you guessed it, too much work-in-process. Unknown dependencies can lead to too much work-in-process because if you're unsure of what is dependent on something else, there's a tendency to take on too much work at the same time to try to ensure all dependencies are met simultaneously. Working emergencies and unplanned work immediately creates additional work-in-process. Finally, neglected unfinished work contributes to too much work-in-process by virtue of the fact that it remains unfinished and in the back of workers minds while taking on additional work. All of these other thieves can exacerbate the amount of work-in-process, and while there are many ways to mitigate some of them individually and we'll talk about that in later lessons, the best thing to do is to set WIP limits in an effort to create improvements that increase workflow. So, how do you apply WIP limits in the first place? A great source of understanding how to apply WIP limits comes from thought leader John Cutler in an article called, Describe Strategies for Applying WIP LImits. Colour talks about how limiting work in process is easy, you just do it. Only work on N number of things at once, start the next thing only after finishing something. Essentially, he's describing a pull system. In this description Cutler is trying to tee up the fact that most people don't believe that practicing with limits is actually beneficial to the flow of value. To really understand WIP limits and pull systems, you may also have to challenge your own deep seated instincts. For example, what will we do if people are sitting around idle? Shouldn't we keep them busy? What will we do about our blocked items? What if swarming is uncomfortable? What if we can get more work done at once? Shouldn't we try? How can we plan unless teams and individuals commit to doing a batch of work ahead of time? To top things off, the benefits of WIP constraints and pull don't show themselves immediately. Initially, things will get harder, whereas before you generally worked around and pediments and constraints and eked out work or tried valiantly to have successful sprints. Now, you'll have to challenge the elephant in the room, while you do, those outside the team will wonder what is going on. It can be very tough. One day while working at Starbucks, I had an observation after working with the teams for a few months. They were constantly getting asked to do what's called discovery work. I defined discovery work as when an idea comes in, often the team is asked to give high level estimates, a high-level solution, and a few options potentially. As I shared earlier, if discovery work is not planned then it's considered unplanned and causes a lot of disruption to teams. To help with this challenge at Starbucks, I applied a WIP limit of one to discovery activities, and also prioritized the discovery request with my stakeholders. At first, stakeholders were frustrated with us. However, once we were able to fully complete discovery requests within a week sometimes sooner, the stakeholders realized this method yielded better results. In a lot of these cases when you first start practicing these techniques, people may resist. My advice is to be persistent. As stated in the book, Accelerate, we don't use WIP limits in isolation because it's simply not effective. We employ the use of visual displays via Jira and feedback loops from production. Implementing an entire system like this is what allows us to deliver work products more efficiently and effectively.
