Before we learn about the Agile method, let's find out what were some of the reasons that led to the emergence of Agile methods. If you look at the Waterfall method, it logically makes sense. You define what you want to build, and then you design how you're going to build it, then you build it, then you validate it, and then you deploy, and users use it. So what were some of the challenges that the software industry was facing that led to the emergence? The first one was in the verification phase where you put all the components together and you try to find out whether the system is working as expected. Well, they were seeing a lot of unexpected issues during that phase. So you may wonder what caused that problem? Did they not design properly? Did they not look at all the different components at that time? Well, maybe the case. Maybe in some cases, that might be the case. But what they were finding is that software systems are very complex, and to predict how different components are going to interact with each other and how they're going to behave is very difficult. And since these defects were found very late in the process, it was very expensive to fix. Then another problem they were finding was after the software is developed and deployed, the users were using the system and they were saying this is not what I was expecting, or this is not what I need, this doesn't work for me. And the clients were saying well, I invested so much money or so much time in building the software and not getting the benefit that I predicted. So you may wonder that did we do a good job in requirement? Maybe we didn't spend enough time in the requirements. Well, that may be the case in some cases, but what software industry was finding out is that predicting requirements, or predicting user needs, is very difficult. So a user really needed something like this kind of swing, but we thought they actually needed this. And then the translation problems starts where the architect or the designer thinks actually user needed this, right? So, they interpreted the requirements incorrectly. And then the developer looks at it and just say this doesn't make sense. They probably need this. So as you can see, the user needed something else, and we built something totally different. Another reason for this problem could be the market shift. So when we were writing the requirements, the needs were correctly identified, that this is what the user needs. But by the time, by the long journey of software development, after we have done development, the market has shifted and the user doesn't need this anymore. And so the problem is not that we are discovering these problems, but the problem is we are discovering these problems very late, which makes them really difficult to fix, or very expensive to fix. As industry was finding these issues, several teams and several leaders were trying different methods like Crystal, XP, Scrum. And they were getting some success. The fundamental idea behind most of these models was to reduce the learning cycle. How can we learn faster? And to increase the collaboration between the team members. So as these teams and as these leaders were finding success in their methods, they thought, "let's get together and find out what is it that we are doing that is making us successful? And what is it that is common?" So these 17 individuals, they came together in February, 2001, in a ski resort and talked about each of their methods and said what is working and what is common in all of these methods? What came out of this meeting was symbolic. The manifesto for Agile software development. It consists of four values and twelve principles. As you can see, they didn't define a new model or a process, they defined a mindset, an agile mindset, that helps teams build better software.