In this video we're going to talk about XP, which stands for extreme programming. XP is a full software development life cycle methodology kind of like Scrum is. Unlike Scrum, XP actually has a bunch of practices that specifically relate to creating and testing software. The software itself whereas Scrum doesn't really prescribe that. XP was formalized in 1999, by a book called Extreme Programming Explained which was written by Kent Beck. And here is a great diagram that Don Wells, who was another one of the early proponents and creators, pioneers of XP techniques, he put this diagram together. So, like Scrum, XP prescribes iterations and in the current version of Kent Beck's book this is at one week, so the XP iteration is at one week. And now they also have this outer loop the idea is that, and this is quarterly at this point. That quarterly they look at the big picture of what do we want to do in the next quarter, how did the last quarter go, what are the big themes, ideas that we want to focus on in the coming quarter. And then they're in these one week iterations. It is very test-driven, there are daily stand-ups and you see this pair negotiation item here. This relates to the way that developers actually work together. So pair negotiation refers to the process of two developers discussing approach and figuring out what they want to do together. Another practice that we'll talk about is pair programming where the developers actually work together simultaneously writing the code in pairs. There is a big emphasis on unit tests. These are small tests that test specific functions or classes, units of code. And you probably heard me talk about the test orientation of agile quite a lot, and this methodology, XP, really specifically prescribes the use of these unit tests as a way to make sure that the code is up to date, that if it's changed and XP recommends rigorous refactoring and doing it quite a lot, you make sure with the unit test that all the code is okay. And you can automate them to build and know that very quickly. You see this pair programming, which is kind of part of this negotiation process. That's the way that this is moving from the general and the longer loops to shorter loops. Pair programming is a way that code is created between the parties. Now let's talk about a few of the specific practices from XP. There are 13 primary practices. They use stories, much like we saw with Scrum and with Agile in general, and they use these weekly and quarterly cycles we talked about before. So the idea here is that these are individual units of working software, and here sort of stepping back and a little bit looking at, more so, the big picture, how things went, how we want them to go. Slack, which is the practice of making sure that you have enough time not only to finish the functionality you want to execute, but also to make sure that you've refactored the code and the test infrastructure and the overall system. In a way where it's getting better and better and easier and easier to add stuff, rather than harder and harder to add stuff. That's what slack refers to and this is a specific practice of XP, making sure that you're always leaving enough time to refactor the code and make it better and better, easier and easier to enhance over time. So that you don't end up with this problem of technical debt, that we talked about before with Scrum. So, these are the processes, learning and deciding, and the practices and how they relate to each other. We've talked about before these practices of learning and deciding are very tightly linked to each other. In the next video, we'll go through the building and managing processes for XP.