The term “agile” is a widely used term both in the real world and in software development. But what does it actually mean?
Let’s dig in: According to the Merriam-Webster’s thesauraus the word “agile” means “having a quick resourceful and adaptable character” and “ability to move with quick easy grace”.
In dog sports the term is used for competitions where the dog must be able to pass various obstacles as fast as possible.
Within climbing the “agile” is used to describe the climbers skills of balance and finesse – without it you will fall!
“Agile”, as known in software development, grew out of a group of developers in a skiing lodge in Snowbird, Utah (USA). The group consisted of 17 persons who later turned celebrities within the community: Alistair Cockburn, Martin Fowler, Ken Schwaber, Jeff Sutherland et al.
Their initial invitation to the lodge was titled “lightweight development methods”, but they collectively disapproved of the negativity in the term and renamed their work and on February 17, 2001 they published “The Agile Manifesto”.
Historically speaking they didn’t invent anything; however, their innovative minds were building on top of the incremental software development methods initially described by E. A. Edmonds back in 1957. The meet up in Snowbird was the culmination of many innovative software developments that came out of the mid-1990s as a reaction to the heavily criticized waterfall development method.
The first official agile development methods were Rational Unified Process (RUP), Scrum, Extreme Programming, Crystal Clear, Feature Driven Development to name a few. Their common denominator was a heavy focus on people interaction over processes and artifacts.
Before the agile methods were introduced, most software development project followed either no process or the waterfall inspired processes.
Developing with no process is often described as cowboy coding, were each developer is fighting a lonesome war against the everlasting flow of requirements. This has obvious advantages and disadvantages. On the negative side: quality control is missing, requirements are not documented, and software degenerates over time. On the positive side: fast adaption of new requirements, fast time-to-market, and swift interaction with customers.
Developing with waterfall inspired processes is a step in the total opposite direction: Each requirement is well documented and a formal sign off is made. After that the developers hide in their coding caves until their time is out or the requirements have been implemented. This method resembles a contractual relationship and is prone to lawsuits or software that doesn’t meet the customers’ expectations. In some cases the contractual relationship is still desirable, at least from a budget perspective, but in most cases developers will need higher frequency of customer interaction to be able to hit the expectations of the customers.
After introducing agile in software development – particularly Scrum – the relationship between developers and customers was changed. The customers’ needs to be involved in the development loop by iteratively refining their requirements and adjusting them as they see the implementation. In general, Scrum is nothing more than a waterfall process with very short cycles in it. But the duration of these cycles (also known as Sprints) is the key to the success of Scrum. By involving the customers at a higher frequency they are forced to take responsibility of their ever growing requirements. This means that they are aware of the consequences immediately when they introduce changes and thus the scope creep is killed.