 So, next up we'll start introducing a couple of really popular agile methods and one of the first and very influential ones is called XP or Extreme Programming. Extreme Programming is this kind of endless loop of activities in which you select a number of user stories, which are kind of small requirements, but they have a very specific user attached to them and we'll get back to that. Then these are broken down into tasks, so it's kind of a high level requirement, it's broken down into technical tasks that a developer can actually do and that can be distributed to different developers. The release is planned, what do we need to release this current increment and then the actual development integration and testing takes place in an intertwined manner, so whenever we have something developed, we integrate it and test it and do that incrementally. Then we release the software and re-evaluate it with stakeholders, with customer representatives, for example. And these iterations take, typically, or they just continuously go on for individual releases, but releases could even happen several times per day theoretically, but typical values are probably two weeks or so. In XP, there are a number of different techniques that are prescribed that you're supposed to use, different activities, and I will just introduce four of them and these are very, very influential, so they have been taken on by different agile methods. There are maybe not that many that are using XP in a pure form nowadays, but at least these activities have lived on or agile practices. The first one is called test-driven development, or short TDD, and the idea in test-driven development is that you don't do development and then testing, but you actually write your test before you start developing. So not just start writing code and then test it, because that usually leads to the tendency to just write the test in a way that it fits your implementation, but it might not fit the actual requirement, so you might test the wrong thing just because you already know how you implemented it. So the idea is if you instead write your test first, you will focus much, much more on what is needed, what needs to work in the end, and then you do the development until the test passes. That's the idea in TDD. In practice, there are a number of studies, scientific studies, it's debated whether this is actually working well, whether it leads to a higher quality code. Some companies, some people really, really are into this and really believe it's good and there are definitely others that think it's a waste of time. There's definitely one thing that's true about test-driven development, it's quite difficult to do that. So when you start doing it, it will be really, really hard to write these tests because you don't quite know what to expect. So test-driven development, write your test first, then write the software to make the test pass. The next practice is called pair programming. In pair programming, as the name suggests, you pair up your two people and you're programming together with one computer, with one keyboard, with one screen. And there's always one person that is writing and the other person is asking questions or commenting. So kind of discussing what is going on and the person that is programming is kind of explaining what he or she is thinking, where it's going. And this practice is really good, first of all, to avoid bugs because two eyes, two pairs of eyes will spot more issues. And it's also great for disseminating knowledge, for sharing knowledge. Because otherwise it's extremely common that the code becomes sort of the owner, it's the owner of the person who has written it and the others don't really know what's in there. So this way you are sharing what you're doing and there are more people that know what the software, each part of the software is doing. It's also great for onboarding. So if you have new people that might not be experienced, it's a great way to introduce them to what is actually happening, how the system is being developed, what the company specific guidelines are, for example. Pair programming is still a method that is used a lot nowadays. Maybe not all the time, but it's definitely something that has been really, really popular and it still is. And it seems to, depending on studies and experiences, it seems to be a really good practice for sharing knowledge, for learning. Then there is something we call simple design. And the idea behind simple design is very often when we write code, we try to think of all the possible use cases and we try to think how could this function, for example, be changed in the future, how, what else could you use it for and you try to make it generic. And back when XP came out, the idea was that very often we overdo this and a lot of the code we write is never being used because we try to make it all that generic, but it actually is never used in a different way. And in XP, the idea is don't overdo design, just do it simple so that it solves the problem that you have right now. Don't try to think ahead too much because things will change. So do it basic, implement it until it runs and then stop. Don't try to make it super generic. And then finally, a very radical practice at the time is the idea of sustainable pace. Back in the 90s, it became very, very common to have so-called programming death marches, where you had essentially a deadline, a milestone coming up and the teams were working crazy over time just to get it done. And the idea, which I think is much more acceptable nowadays, is that this is not sustainable. It'll just burn out people and the quality will actually not become better because people are tired, they're stressed, they will make mistakes. So the idea in XP is continuously have this sustainable pace work a reasonable amount of time, but don't overdo it. If you don't finish, you'll just do it in the next release. So that's the idea. And these are just four practices in XP, but they have definitely been influential and they are still around some more than others, but you'll find them in more the modern agile or other development processes. So that's XP. Next up, we'll dive into scrum, which is another really, really popular agile development process.