All right. Let's talk about the job of deciding and how the different agile methodologies, that you've learned about, apply to these tasks that we've been discussing. And the first is Kanban. So it's focused on Work-in-Progress and minimizing the amount of Work-in-Progress and looking at how you can make the work flow better really informs all of these things. For prioritizing and batching tasks, it'll give you a clear idea of how much you're going to get done and avoid the potentially wasteful process of estimating, and over-estimating, and trying to predict things that just aren't that predictable. And for prioritizing items, it will help you understand how your priority items are flowing through, getting done, so that you've got them as a bird in hand, rather than a bird out in the bush, and you don't know when it's coming in. For the job of sharing out responsibilities and tasks, those WIP limits will give you a nice tool to explicitly look at how material is, how concepts are flowing through your delivery process from idea to execution, and how well that's working, and what your current point of view is. The WIP limits are nice and that they enforce that, and they give you a nice explicit backdrop to use to discuss and make decisions about how to improve it. And then for defining and communicating release content, Kanban's focused on really looking at how things go all the way across your process will give you better actuals to use to look forward and figure out what is likely to happen by a given date. So that you can make other related decisions. Scrum and XP both have a specific set of processes and kind of plumbing to help you make and manage decisions. And they're these two techniques that effectively implement the iterative deciding, executing, and observing loops that are really integral to what Agile actually is. They both prescribe relatively short cycles. Scrum runs between one to six weeks. Whereas, XP recommends one week cycles. And then quarterly reviews, to figure out how things are going. What are you generally focused on and so forth. They both use backlogs and they both have a planning meeting, where you decide what you're going to execute and discuss the content, so you make sure it's well understood and testable, executable, actionable terms. Scrum says that if you have a big change, let's say a big news story that you do or don't want to do all of a sudden in the middle of an iteration, that you should scrap that iteration. And restart a new one. Whereas XP says, it's okay, just bring the new stuff in re-prioritize and the implementation team will figure out what they should do. They have a little bit of a different point of view about decisions mid iteration in that way. And then they both use this Daily Stand up which is very much a common almost ubiquitous feature of people doing Agile. One thing that XP has that's kind of unique and again this sort of feature of XP that it goes down into the sort of working moments to a greater extent than Scrum is this idea of Slack. Slack is this whole rubric of making sure that you provide enough time to do more than just the obvious things that you've absolutely got to do to make a narrative actually work. It's the idea of giving your development team enough time to refactor and change code and. Build things in a way where you're not accumulating technical debt, but rather you're at least not accumulating it. And ideally, you're drawing it down so that the code is easier and easier to enhance over time. Now, this can be a very contentious topic among the sort of management roles and the execution roles. The management roles are worried that there are scene bagging or taking up too much time to do things and the dub and tester roles know that if they don't have time to do things correctly, that it's going to get harder and harder to deal with the code. They're going to be blamed for becoming slower and just things are going to get worse. Now, the obvious answer here is make sure the dev team has enough slack and that's true. Enough slack is going to help you get an asset, a code base that get's better and better and easier and easier and hence over time and not enough Slack, too much tension. I don't have the strength to actually break this rope, but too much emphasis on putting in too many features, will break it. It will break the integrity, and the longevity, of your codebase. While most developers are, probably, trying to do the best job they possibly can. A lot of managers will always wonder if everybody's working fast enough. So my general advice is build the trust over time that the team is factoring in the right amount of slack. And talk about the hypothesis that, is this working for us? Are features at least as easy to implement as they were, or are they ideally getting better? I mean, how is our slack going? And ultimately it's the team that collaborates together on what's going to work out best that is going to be the most successful. And that's one of the most important things as we go over this job of deciding. That these decisions are made collaboratively and that you're always trying to evolve the way that you're making them so that the team's performance is enhanced as they go along. So we've talked about the job of deciding, how to become decisive, yet flexible. And how to make sure that the decisions are made in a way that enhances the quality and the output of the whole team. So good luck with the job of deciding, and I think that you'll make good decisions. Don't try to make them perfect, but think about them in the larger context and try to always make them better, and you'll be fine.
