This article originally appeared on Capterra: The Ultimate Guide to Agile Software Development.
Project management is a complicated field; there are a plethora of methodologies, software options, team member roles, and expectations that vary, not just within organizations or industries, but across the entire field of project management itself.
There’s rarely a process improvement claim that the project management community doesn’t scrutinize. From emphasizing extroversion versus introversion for project manager personalities to which project management software is best for the business, there’s rarely agreement on anything.
One trend, however, has been growing since 2015 and earlier: Agile project management use is on the rise (and it’s great for software development!).
With all the emphasis on agile customization, or Scrum vs. Kanban, or any other project management methodology quibbles, it’s easy to lose sight of what agile software development actually is–and how it works.
The History of Agile
The Institute of Electrical and Electronics Engineers can trace rudimentary agile project management methods all the way back to 1957 in Los Angeles, where Bernie Dimsdale, John von Neumann, Herb Jacobs, and Gerald Weinberg worked closely together on developing software for IBM and Motorola. Craig Larman, while quoting Weinberg in his article “Iterative and Incremental Developments. A Brief History,” said,
“Waterfalling,” or the waterfall model, was the prevailing form of project management at that time. It’s closely affiliated with Gantt charts and lays out what tasks need to be done at what points in the project in order for the project to move forward.
Using this method, software development became incredibly difficult. While the waterfall method relies on predictability and sequence, software developers needed a more flexible project management method that made room for error, bugs, setbacks, and the independence affiliated with the software industry.
It wasn’t until the 1970s that a more formal approach to agile took hold, led by Dr. Ernest Edmonds, Tom Gilb, and the New York Telephone Company’s Systems Development Center. The ideas were not widely appreciated. In fact, when Dr. Edmonds presented his idea to the Journal of Computer Aided Design, it was immediately rejected. The sole comment the journal sent back to Edmonds was, “If you don’t know what you are going to do before you start you shouldn’t start!” He then took his work to General Systems, which eventually accepted his work.
In the 1990s, software developers were at their wits’ end. This cohort of programmers, largely of the Generation X demographic (born between 1961 and 1983), were “latchkey kids” and carried over their anti-establishment teenaged years to the office. As Craig Larman discovered, developers found waterfall “heavily regulated, regimented, and micro-managed.” It wasn’t working for this cohort.
The 90s brought forth many lightweight and versatile project management approaches to software development, including dynamic systems development method (DSDM), XP, Scrum, and feature-driven development (FDD). While all of these systems existed before the Agile Manifesto, they are now considered to be part of the agile methodology.
The Agile Manifesto
Between February 11-13, 2001, seventeen individuals met at The Lodge at Snowbird ski resort with three things in common: a love of food, a love of skiing, and a “need for an alternative to documentation driven, heavyweight software development processes.” They, to this day, unironically call themselves “organizational anarchists.” From this gathering, all participants ceremoniously signed the Manifesto for Agile Software Development [PDF], a seven-page document centered around four concepts:
- “Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.”
In his “History: The Agile Manifesto,” co-founder Jim Highsmith writes,
The Agile Manifesto emphasizes that none of the authors believe in a “silver-bullet theory,” hence why nailing “What Is Agile” gets so complicated; the founders did not think that they had all the answers, and they didn’t think there was a perfect one-size-fits-all methodology for every development team. Their approach was necessarily libertarian. They stressed in the document at almost every juncture: “this group is about helping, not telling. The Alliance members want to help others with Agile methods, and to further our own knowledge by learning from those we try to help.”
Perhaps it was the “we don’t know everything, but we do know something” approach to software development that helped the system catch hold.
Read the rest of the article on Capterra.com.