The Ultimate Guide to Agile Software Development

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,

All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for ‘software development.’

“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 EdmondsTom 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), XPScrum, 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,

In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the begeebers [sic] (you can’t use the word “sh-t” in a professional paper) out of traditionalists. Quite frankly, the Agile approaches scare corporate bureaucrats—at least those that are happy pushing process for process sake—versus trying to do the best for the “customer” and deliver something timely and tangible and “as promised” because they run out of places to hide. Editor’s note: we edited the original language to be blog appropriate.

The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.

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