Agile Methodologies

Slide Deck: Software Process and Methodologies - Agile

Why Agile?

In 2001, a group of software engineers met in Snowbird, Utah to discuss what it really meant for a software process to be “agile.” There were representatives there from the first folks that created Extreme Programming, Scrum, Crystal, and a few others. The account of the meeting goes into a bit more detail as to how the discussion emerged and eventually settled on the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

To put it simply, plan-driven methods, while essential for some types of software development, were overkill for the smaller, leaner projects that were becoming the norm at the height of the dot-com bubble of the early 2000s. If you weren’t able to get your product to market as soon as possible, then you were left behind. Documentation, in many cases, was seen as a hinderance, not a benefit.

While the burst of the dot-com bubble did see many of these projects fail (ahem pets.com ahem), the concepts from agile took hold with these developers. They saw the value in being more customer-focused, rather than contract-focused. It was these developers that went on to major companies like Google and Amazon over the next decade, helping to change the way large companies built software.

The Key Difference

If you can only have one aspect of a project to look at to determine if it should be built in a more plan-driven or a more agile way, the best aspect to consider is how often the requirements will change.

• If you are plan-driven, you want the requirements to change by less than 5%. Plan-driven methods require that requirements are stable because you are writing a lot of documentation and design based on those requirements. If the requirements change during development, that negates a lot of work that was done and makes it difficult to communicate those changes to everyone involved.
• If you are agile, you are more suited to requirements changing more frequently. Agile, by its nature, relies on customer communication with the developers. While plan-driven often works for projects where the customer base is large (e.g. Gmail), agile works better when the developers can show the customer an early version of the software, get immediate feedback, and then make the needed changes. Simply put, the iteration cycle is much shorter in agile by design.

---