Software Process and Methodologies
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.
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.