There are some key differences between a traditional Waterfall project and the AGILE project. So let's have a look at these. So with Waterfall we tend to have a detailed, long term project plan with a single timeline. With an AGILE project, we tend to have shorter planning based on iterations and multiple delivery points. Waterfall tends to be definitive and rigid project management and team roles. So it's very structured in the project management process and in the team roles. Whereas, our AGILE project tends to be as flexible as possible and cross-functional team composition is encouraged. For Waterfall, changes in deliverables are generally discouraged because they are costly and they sound difficult. 

Whereas, with an AGILE project, changes in deliverables are expected and encouraged. For the Waterfall method, we tend to have a fully completed product delivered at the end of the timeline. Whereas, with AGILE, changes in deliverables are expected and less impactful and the product is delivered in functional stages. We tend to have a contract-based approach to scope and requirements with Waterfall. Whereas, with AGILE, we tend to be collaborative and interactive. Our requirements, the customer is involved throughout the Sprint Cycle. I think we see with Waterfall a linear phased approach, which creates many dependencies. The whole idea of a Waterfall approach is that you do things in a linear fashion, where one is completed, you move onto the next one. Whereas, with AGILE, you tend to have a concurrent approach. So you can spawn many project cycles at the same time, independently of each other. So you actually get more done and there's less dependencies on one piece of work being finished first. 

I think AGILE definitely suits development projects, in my experience. I find it the fastest way to get software to do the things that you want. With Waterfall, in my experience as I mentioned earlier, felt like it was always difficult to get change put in place, that change was seen as a bad thing and that generally, we were running to try and meet a deadline with many, many hold-ups. Meant that testing often didn't get done correctly at the end of the project. I also find that developers love working in the AGILE way. So the self-empowerment thing is important. People feel more empowered in the AGILE framework. They're less likely to feel resentful of being asked to do things, if they're given the opportunity to try and solve them with their own initiative. 

And the idea that projects or project teams are not able to run without the management level of a project manager, I think is completely void. I don't believe that at all. So over to you how you run your projects. Okay, that brings us to the end of this Introduction to AGILE course. Let's just quickly summarize the concepts we covered. In this course we've learnt to recognize and explain the AGILE methodology. We've learnt to recognize and explain the AGILE Principles and how they relate to software projects. And we've learnt to recognize and apply the AGILE roles and responsibilities. Thank you very much for your attention. If you have any questions or comments, please feel free to contact us at support@cloudacademy.com. Thank you.