Before I dive into the agile methodologies, I would like to give a high level overview of some common project management methods methodologies. We have the waterfall methodology, rapid application development also known as rad methodology and agile methodology. By the way, these are not by any means the only project management methodologies out there, but these are the most common ones. So, I wanted to give a high level overview So, you can appreciate similarities and differences between agile and these methods, methodologies and also see pros and cons between these and agile methodologies. So, first we will go over the waterfall methodology. This is this has been a methodology that has been used for a while and it has been you it's one of the more common methodologies out there.

These This was introduced by Dr. Winston Royce in a paper he published in 1970. Basically, this methodology emphasizes the logical progression steps of a software development lifecycle or sdlc, which is basically you start with requirements, you complete the requirements for the software, then you get into the design phase, you complete the design phase, then you get into the implementation phase or the coding phase of the software. You go through the verification or QA step you install the software and then you are in the maintenance mode for the software where you are supporting the software. This by the way can be followed for other project manager and project management's other than software that is, as well. Some of the good things about this methodology is it's very intuitive. It follows a logical progression of sdlc or software development life.

Cycle. Some of the disadvantages of this methodology is that product owner or the person who's providing the requirements may not comprehend all the different requirements prior to looking at a working product. Also the design the designers may not be able to predict all the difficulties that need to be accounted to account for. Another one is if the testing since it happens to after the coding phase or after, after what is called the implementation phase. If there is a design flaw that is discovered or is identified at that point, you will have to get back into the design step back again, and now you have to go through the design, redesigning and then implementation and then back into the QA phase. Also, it ignores midstream client feedback.

If any feedback or any changes need to be made, you have to go through a whole change management lifecycle with Once the change has been accepted, now you you go back to the design phase and then go to the implementation and all. So that's some of the pros and cons of waterfall methodology. Next we have the rapid application development or rad methodology. This methodology is kind of a middle ground between waterfall and agile methodologies. This was developed by James Martin at IBM in the 80s. And it's also published in his book rapid application development in 1991.

I provided the ISP ends here just in case if anybody is interested in reading the book. Basically, the read follows the following principles. requirement gathering is through workshop or focus groups. So basically what happens is all the stakeholders are put into a room they basically brainstorm all the requirements out it may be one session at Maybe multiple sessions that all the requirements are captured. The next phase is basically to create a prototype instead of creating the actual product, a prototype is created. This kind of gives a visual of it based on the requirements captured, what is the product going to be looking like and it's also kind of gives them a feel for if there are some early design issues that they need to address etc, if you will.

Also read emphasizes modular or reusable software components. Why is it important? The reason it is important is if you have certain libraries that are going to be used for multiple different software's libraries, meaning modules that are being good using multiple different software's, if you create it for one software, you don't need to create write the same code again and again for each time another software application is created. So one, it saves some time. Second, once it has been created and fully tested, you basically can create it as a black box. And you don't have to do as much testing on this, this module again, you can accept, based on the testing that has already been done on this.

So, so that's kind of a very positive leap in red. There are less formal reviews, there are more informal reviews. So you can catch the bugs easily easier, if you will, or earlier on, if you will. Also there's it's iterative. So there are rigid durations for an iteration. And you basically do this in not that you don't build the whole software in one phase, but you have iterations that you build the software in, if you will, again, this can be used in outside of software as well.

This methodology so that's basically The rad methodology. Next, I'm just going to go over the manifesto for Agile software development in this lesson and then in the next lesson, we'll dive into the different agile methodologies, if you will. So, what is the manifesto for Agile software development? If you can keep this in mind, you would appreciate the foundation of the different agile methodologies, if you will. So, it says individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration, over contract negotiation, responding to change over following a plan. These are the important differences.

This is what these are the foundations, what the different agile methodologies are based on the right hand side is mostly waterfall. And the left hand side is is basically what agile is founded on. While the ones the items on the right hand side are valuable. What agile considers more valuable is the items on the left hand side. So it it, it doesn't ignore the altogether the value the items on the right hand side, but it puts more emphasis to the to the items on the left hand sides. Again, individuals and interactions people over processes and tools, people and people's interactions people's communications over processes and tools are more important.

Working software is more important. Over comprehensive documentation, a lot of documentation, customer collaboration, working with with the customer is more important than negotiating the contract. Responding to change is more important as compared to following a rigid plan. So that's kind of high level, the foundation of agile and also high level the an overview of the different project management methodologies. In the next lesson we are going to talk about specifically the different agile methodologies are we going to start talking about the different agile methodologies