Introduction to AGILE
The course is part of these learning paths
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.
This course will suit anyone interested in learning what AGILE is and how AGILE techniques are used in development projects.
- 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
- 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
So let's get into the roles, Product Owner. The product owner represents the voice of the customer and has the authority to make decisions about the product. The product owner is responsible for making sure that the product meets the requirements of the users and the customer. So the product owner needs to keep focused on the business side of product development. The product owner should spend the majority of their time liaising with stakeholders, and should not dictate how the team reaches a technical solution. The product owner needs to be able to describe and define the product in user-centric terms, typically called user stories. So it's not a technical role per se, and the product owner should refrain from technical discussions. The product owner owns the product backlog and is responsible for communicating the vision to the team, and defining and prioritizing backlog items. The product owner needs to work with the team on a daily basis to discuss requirements, answer questions and provide product guidance. Scrum teams should have one product owner, and the product owner should not be the Scrum Master. The product owner needs to be one person and not a committee. Communication skills are a core skill for the product owner to acquire and master. The ability to convey priorities, and to empathize with stakeholders and team members is vital to ensure the product development continues to head in the right direction. As a product owner you need to really get inside the user's world, to understand what they are trying to achieve. I find one on one interviews with users to be the most effective format, for finding out those user stories and understanding those requirements. However, a story gathering workshop can be used as well to capture and collect user stories from a group of stakeholders, and/or group of users. The next role is the Scrum Master. Now the Scrum Master is the advocate and the protector for the development team. The Scrum Master removes obstacles, mediates discussions within the team and negotiates discussions with external partners and team members to the team. The Scrum Master will liaise with the product owner and negotiate who is doing what by when in the spring tasks. The Scrum Master will select and assemble a development team, and the Scrum Master controls the process. But above all the Scrum Master works for the team. So the development team. While the product owner defines what we are delivering, the development team owns how things will be delivered. The development team is formed and facilitated by the Scrum Master, and as a self organizing unit there is no right or wrong way of shaping a development team. The development team is a self organizing and self managing group of individuals, with cross functional skills. Self managing, hmm, this idea of a team can appear a little off center to project managers, used to allocating tasks to developers and managing delivery of work units. Now remember the foundation stones of our job. We want to encourage individuals to use their skills. To show initiative and to take ownership. So at heart, accepting Agile as a process may require you to first let go of a few traditional project management beliefs. The development team size should be small enough to remain nimble and large enough to complete significant works within a sprint. The development team usually consists of three to nine people, and that development teams are responsible for the features and functions agreed to in each sprint. The development team own making estimates, making task commitments and reporting status daily to each other in the daily stand up. So the product owners decisions are visible in the content and the ordering of this product backlog. So far so good, but here are where things can get a little difficult. No one should tell the development team to work on a different task or from a different set of requirements than that, that's in the product backlog, and the development team isn't allowed to act on what anyone else says. So that requires a bit of a change in the way most business teams tend to integrate and do things. For the product owner to succeed the entire organization needs to respect the decisions of the product owner.
Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built 70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+ years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.