What is AGILE and how it is different

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
Students725
Ratings
4.9/5
star star star star star-half

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

Okay, so let's think through the problems that agile attempts to solve. The biggest issue I've faced as the owner of a development company was the inconsistency with development projects. I had a software development company building online applications for the insurance industry. So between 2000 and 2005 our development process went something like this. Our business analyst wrote a business requirements document, our development lead wrote the functional specification, and as a team we built a time and budget proposal for the end-to-end application build. The customer signed off the specification timeline and budget. The project managers ran the project using Microsoft Project, and the get chart was the source of truth for us all. But here's how it played out in reality. Pretty soon into the development the customer realized they needed something not described in that functional specification. The customer would create a change request. We would document the change request, estimate the work required to fix it, propose a change cost if it was required, and ask the customer to accept that proposed change. Now this process would happen over and over. It was slow and painful. Now we did practice RAD, or rapid application development, practices in how we built our code. But the agile documentation that came available in 2005 really made it easy for everybody to understand how to do this. It wasn't an overnight shift by any means. But straight away we could see how agile made it easier to discuss and share ideas. Agile was popular with customers as well as with developers, and so over time agile became more prominent in how we designed and delivered software projects. The most improved change for me was moving away from having a static project specification document, as inevitably the requirements of the application would change, as we all learnt more about how the end users actually needed to use the software. As the developers that meant we would actively discourage any change from that specification. Change was seen as a problem. We immediately labeled any change an exception. An exception meant we had to renegotiate the overall project timeline and budget with the end customer. Now this made for a kind of compromising working environment as the customer just wanted software to do what their end users needed, and we just wanted to complete the project on time and within budget. So running projects like this for five years was hard work, and honestly success was hit and miss. When agile became more prolific in 2005 I leaped at it with open arms and I changed my way of thinking about projects and code. So let's review the problems agile sets out to solve. The first is that traditional documentation doesn't adequately record and reflect the actual requirements. It's so difficult to describe and capture user requirements in a traditional requirements document. The problem is that requirement documents are static snapshots of a set of requirements that doesn't suit software development. And I think we all have struggled to describe functions and features using this functional requirements format. Now business analysts spend a long time writing requirements. Customers try to match them back to what they originally wanted and developers tend to avoid them. So the functional specification document was an unpopular part of the project. And the proposal that accompanied the functional specification was, at best, a projection based on what that point-of-time snapshot should look like. So with the traditional project plan we worked to a critical path. If one aspect of the project takes longer than expected, the entire project would be impacted. So the second problem is that it's difficult to manage projects in a linear manner. Projects, and life in general, is a series of irregular events, things in life and so in projects rarely flow evenly from one event to the next, like a get diagram does. So trying to apply a linear order to things is like trying to make water flow in a straight line. Agile encourages events to occur concurrently and independently. Third issue agile attempts to solve is the top-down approach to projects disempowers our most important asset, our team members. The intelligence of individual contributors. The concept that developers are unable to manage themselves without the expertise of a project manager is a myth in my view. To get the most from collective sums of parts we need to encourage self management by empowering people to self prioritorize, take initiative, and to act autonomously. And the fourth one is testing. In traditional projects testing is nearly always last, which means that often just doesn't get done 'cause you're already out of time.

About the Author

Students52760
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.