 So, the next thing we'll discuss now is the topic of Agile development. And as discussed at the beginning of this course, in the late 60s we had what they called back then the software crisis, that the software systems that were built were buggy, they ran over schedule, they were too costly, so back then the vision of software engineering came up. We need software engineering and that led to the creation of a lot of the processes that we have introduced before. But the situation in the around end of the 90s was actually quite similar. We had still lots of budget overruns, for example the chaos report I've been mentioning came out during that time. There was the dot-com bubble, so lots of things went wrong and generally we were not that satisfied with the way we were building software and that's when a couple of people got together and came up with the so-called Agile manifesto. So they presented, among other things, these four statements that describe what they are doing to develop software successfully. And what they said is that we value these things on the left here over what's here on the right. So, individuals and interactions, having people and talking to each other, is more important, is valued over having processes and tools. So back then it was very common to have very strict processes, very rigid processes at the companies, for example these stages, and you cannot jump over them, but they said well individuals and interactions discussing stuff is much more important than that. Working software is more important than documenting and having comprehensive documentation. Customer collaboration and discussions with customers are more important than negotiating contracts and finally being able to respond to change is more important than following a plan. There is something that is often forgotten in this manifesto because Agile can be presented as the best thing ever. It does not mean that you should not do these things here and that's really, really important. For example, a common thing that people forget is that the Agile manifesto does not say you should not do documentation. They just say focus on getting the software right first, but there is room for documentation. It's just about balancing it in the right way. So back then the idea was about fixing the problems we had because we were very much too far on this side. It's not about throwing all of this away. That's really important to discuss. So this is the manifesto of Agile development, the Agile manifesto that has led to the creation of a number of methods like XP, Extreme Programming and Scrum, for example, to name two very influential ones. But the question is, what is Agile development really? And often enough you'll see it compared to what are called plan-driven processes. And plan-driven, as the name suggests, is very much planning something and then following that plan. And that's contrasted by Agile development where the focus is much more on smaller increments and not planning ahead too far. So there is a plan in Agile, but it's not a very central element. In plan-driven, you very much have, you plan your stages ahead. You do the entire stage and you iterate within that. For example, you do requirement specification and then that's your plan for design and implementation. And then you do the design step. And within the design step you might do increments, iterations, but then you go to the next step. Nevertheless, plan-driven development can be incremental. You can have incremental plans, but the whole focus is really on making plans, having milestones and so on. Agile development is an incremental activity, an incremental process. So specification, design and implementation are intertwined, as we discussed earlier. And what you have is typically a series of increments that are very often called sprints. So in many of the Agile processes, they are called sprints and they can take everything from a day to a couple of weeks, typically. But we're not talking about month or years. They are fairly short on purpose. We have or we should have strong stakeholder involvement. So what was mentioned here, customer collaboration. In many cases, it's not just the customers, but also users or other stakeholders. But they should be involved. They shouldn't come at the beginning and the end and nothing in between, but they should constantly be there. Ideally, sit at the office, have a customer representative, for example, that constantly gives input and feedback. There is frequent delivery. So it's not like you get a running system after a year, but the idea is, ideally, after each of these increments, get some working software product. And usually, this requires a fair bit of automation, for example, automated testing, so that you don't need month for testing, for instance. And finally, we don't like documentation as much. So try to keep the documentation minimal. And again, this does not mean no documentation. In many cases, there is documentation required. And in many cases, documentation is good to have so that you can still understand your system in a year or two from now. So this is what agile development is. But very often, we go back to the agile manifesto that describes the values, what is valuable in agile development and what should we reduce if we can to the necessity. So that's what agile development is from a bird's eye perspective. But now we go into details on a couple of common agile development processes or methods, a couple of activities.