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 10 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
AGILE Practices are techniques applied during phases of the software development lifecycle. There are many practices that carry the AGILE label, as they do follow the principles outlined in the AGILE manifesto. But there are two concepts that I think are most important to AGILE Practices. The first is Continuous Integration, also known as CI, and it's a common AGILE engineering practice where code changes are integrated into the main code branch as frequently as possible. An automated bill verifies changes, which reduces integration did, taking out some of the undifferentiated heavy lifting and the things that often hold us up in deployment, and we have a continually shiftable main branch.
The other cool component is Continuous Delivery, or CD, and that's the process of building, testing, configuring, deploying from a codebuild to a production environment. Now, Continuous Delivery enables you to run multiple testing or staging environments. However you so choose to test and review it is entirely up to you. And then use a release pipeline to automate the creation of the infrastructure and to deploy the code or applications. So, Continuous Integration is a major influencer of Continuous Delivery. The two go hand-in-hand. As Continuous Integration starts the pipeline process after a successful completion of a test. Now, before Continuous Delivery, software release cycles could often become a bottleneck for application and operation teams. Manual processes could result in unreliable releases, which often resulted in errors both big and small, which ultimately led to delays in releasing code builds. Having an automated release pipeline allows you to take a fail-fast approach to code-testing and code-validation. The less-complex tests are run first, and so results are captured early. While the longer-running tests happen after the less-complex tests have completed successfully. So the goal of CD is to reduce the build time by finding the shortest path from the availability of new or modified code to the actual deployment. By using automation, Continuous Delivery minimizes the time to deploy and the time to mitigate, or time to remediate product incidents. And these are often referred to as TTM and TTR. So the CD approach reduces process time and eliminates idle time.
To deliver value to your N users, you need to release continually and without errors. So Continuous Delivery is made easier by using infrastructure as code and by automated testing and monitoring. Scrum is one of the most common AGILE frameworks and the one that most people start with. So let's talk about Scrum and get an understanding of what Scrum is. Scrum is an AGILE framework for managing work with an emphasis on software development. It is designed for teams of three to nine developers who break their work into actions that can be completed within time-box iterations, which we call Sprints. Now Sprints can be 30 days or less. Most commonly two weeks. And we track progress and re-plan in 15 minute standup meetings, which are called "The Stand Up." The roles of Scrum are important to understand once you start practicing it. Scrum is loosely based on the game of rugby, a game that I love. In rugby, you work as a team to pass the ball up the field. Each player has a set of strengths, however their roles or position can change to help get that ball across the opponent's line. The Scrum is used to restart the game, and in a scrum players huddle closely together, lock heads with the opposing side, and when the ball is put into the scrum, each team contests that ball. Then, they start moving forward where they're as a team.
This idea of moving down the pitch together is what I believe the original founders of the Scrum ideology had in mind. I'm not going to get into a definitive history lesson on Scrum, but since 2009 there has been a public document called, "The Scrum Guide", that defines a managed version of Scrum. So check it out if you want to read some of those rules. So the lines between Scrum and AGILE have become somewhat blurred over time in their roles and practices. The important thing is being able to get started using these roles and processes.
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.