Course Summary

The course is part of these learning paths

DevOps Playbook - Moving to a DevOps Culture
course-steps 6 certification 2 lab-steps 1 description 3
play-arrow
Start course
Overview
DifficultyBeginner
Duration37m
Students652

Description

Course Description

AGILE has become the de facto framework for innovation at scale,  and knowing AGILE processes are a baseline skill for any organization looking to leverage the speed and flexibility of cloud services. The introduction to AGILE course covers a broad spectrum of topics from how to hold an AGILE meeting to deconstructing its key concepts, techniques and best practices.

In this short course, made up of ten lectures, we introduce you to the key concepts, roles, and techniques of the AGILE methodology so you will be able to recognize and explain the agile process in work situations.

Intended Audience

This course will suit anyone interested in learning what AGILE is and how AGILE techniques are used in development projects.

Learning Objectives

  • Recognize and explain the AGILE methodology
  • Recognize and apply agile principles and how they relate to software projects
  • Recognize and apply the AGILE roles and responsibilities

Prerequisites 

  • Anyone interested in understanding what AGILE is and how the AGILE methodology can be used in software projects.
  • AGILE is technology independent - You don’t need a technical background to learn how to practice AGILE in business projects.
  • This is a beginner level course, so no previous experience of AGILE is required.

 

Transcript

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.

About the Author

Students51665
Courses77
Learning paths28

Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe.  His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.