The Birth of Agile

By Paul Rakowicz, VP of Software Development

Today’s blog is a primer on Agile.

To get started, let’s take a quick look at the Agile origin story and the formation of the Agile philosophy.

Briefly, it all began with a gathering of 17 individuals in February of 2001. Seventeen individuals who came together and, meeting from the 11^th through the 13^th of that month, began to refer to themselves as “The Agile Alliance” — ultimately producing the now famous Agile Manifesto.[1]

Putting pen to paper, here’s what they declared:[2]

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.

These words — this Agile Manifesto — led to a fundamental change in how both software is developed and projects are managed.

But what led to this birth of Agile? Why is it that these 17 souls met in the mountains of Utah to discuss the software development process?

Well, the difficulties of the Waterfall method did, that’s what.

Through practical experience it was becoming painfully obvious that the Waterfall method was producing more failed software projects than successful ones and more unused code than working useful code.

For those still using the Waterfall method today this remains true.

So what are the basics of the Waterfall method? And why was it failing those of us in the software development field?

Let’s take a moment to understand the Waterfall method.

The Waterfall method is a sequential design process used in software development that demands full requirements gathering at the beginning of a project. Those requirements are then used to flow tasks steadily downward into the remaining sequential steps (thus the idea of the “waterfall”). This method was originally defined by Winston W. Royce in 1970, and was the first established approach to building software systems.[3]

There are a number of different definitions for the actual steps involved in the Waterfall method, but they all have some of the following in common:

Requirements Gathering
Analysis
Design
Coding
Testing
Implementation
Maintenance

You can see from all of this that the Waterfall method is based on the assumption that all requirements can be gathered up front during the Requirements phase. Further, the practical reality of this assumption is the idea that communication with the user can also done in that stage, and is only necessary in that stage.

While it was thought the Waterfall method would work well, ultimately practical experience demonstrated that it carries with it quite a few disadvantages, such as:

Users simply can’t state all of their needs up-front in a Requirements stage. They need to be a part of the process throughout, but Waterfall does not engage them in the following steps because of its assumption that Requirements can be gathered all at once and up-front.
Because of this fatal flaw, the software that is developed and delivered through a Waterfall project may often match the requirements as agreed upon, but rarely does it match the actual needs of the client.
Based on the top-heavy approach of Waterfall, it does not cater at all to changing requirements during the development cycle, and so once realized changes are very costly to address.
Waterfall projects tend to be delivered all at once, as the method is based on an all-or-nothing approach, so projects often take substantially longer than expected to deliver because they rely on everything in the specification being complete before anything at all can be delivered.

These problems with the Waterfall method proved to be insurmountable, leading to the realization that another method was needed in order to improve the results of software projects. And so, following the old adage that “necessity is the mother of invention,” it emerged back in February of 2001.

And there you have it, an understanding of the birth of Agile and an introduction to both the Agile and the Waterfall methodologies.

As Agile has proven itself through practical experience to be far superior to the Waterfall method, in future blogs we’ll begin to delve more deeply into the methodologies implementing the concepts of the Agile Manifesto.

In preparation, I’ll leave you with the 12 principles behind the Agile Manifesto:[4]

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.

Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity — the art of maximizing the amount
of work not done — is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

I look forward to next time — when we will begin to delve more deeply into different aspects of the Agile method and its real-world application to solutions project management.

For more information on Lowry’s use of Agile methodology, download our whitepaper Discovering the Lowry DSDM Implementation Methodology.

[1] Learn more details here: “History: The Agile Manifesto”

[2] “Manifesto for Agile Software Development”

[3] “The Waterfall Development Methodology”

[4] “Principles behind the Agile Manifesto”