In this lesson, we'll take a look at combining Lean principles and practices with our Scrum solution to continue to improve and strengthen our unique Agile solution. Lean gives us a lot. Lean practices primarily address visualization of the work in the Sprint, managing the work in process, breaking the work down into the smallest unit task as possible, and smaller tasks go through the system faster. They get to done sooner. Again, we have our work in process limits that promotes better teaming. Obviously, the Kanban board promotes transparency, so we have that Scrum value of transparency. It's a visualization of the work in progress. The team can focus on the current work in progress and if help is needed, the team can collaborate in order to move the tasks along in the column if the work in process is holding up or stopping a particular task from moving. The team can focus on the next section of the workflow in order to complete those tasks and get them to done. Our Kanban Board in Lean supports the Scrum value of transparency. No question about that. Lean practices greatly enhance Scrum as the work in process limits promote better teaming. If we needed to move our work along sooner, so we can see here that we have stories. We have three stories and test with a WIP limit of three and in deployment there's a WIP limit of four. If we completed two of these, we wouldn't be able to move both of them over to deployments. So the team is going to have to focus on getting the current stories, in this case deployed and over to done. That's just the basic idea of the WIP limits help us to better team and get the work to done. Again, the WIP limits promote better teaming. Just as we discussed, the team is going to have to swarming collaborate in order to move stories through the workflow and ultimately to done. The WIP limits prevent long queues from buildings. Long queues number 1, make for idle team members because you might be doing a lot of waiting and also quality goes down when there are long queues. Again, we discussed how teams can focus on particular sections of the workflow and get that work over to done. Work in process limits really are relatively simple, but they can promote a very strong process to completing our tasks. That's what we want to do with our Agile solution, get work done. Our work in process limits on the Kanban Board enable those cross-functional teams. Again, we may have testers that are not specialists encoding. This could be our coding section of the workflow here. But testers can help in some way so that the cross-functional team is in the mindset of being cross-functional. They say, "Well, I don't know anything about Java," say, "but I can spot when certain sections are not commented. I can make sure that the tests are passing so I can help my developers ensure code quality." That's what we want, we want a general knowledge. We can again help each other manage through the WIP limits or the work in process limits in order to bring the tasks through the workflow, getting the work ultimately to done. Work in process limits and task breakdown help us reduce risk and uncertainty. Uncertainty and lack of understanding equals risks, so that increases risk. Our work in process limits and our small tasks help us to reduce risk, help us to reduce uncertainty and unpredictability. We can see here, if we have smaller tasks, we have a better understanding. There are more is known, there were fewer unknowns. Therefore, our risk curve here is reducing. The smaller our tasks are, the lower our risk is. Also, the more work we get to done, obviously the lower our risk is. Lean, in just these two principles alone or combined with the visualization really helps us better team, get work done faster, reduce risk and unpredictability, and also helps us to drive the product to better outcome, a higher customer satisfaction, and more features delivered to the customer sooner.
