Resources > Articles

Method or Madness? Celebrating 20 years of the Agile Manifesto

Author
agile manifesto anniversary

agile manifesto anniversary

On a cold, snowy weekend in February 2001, a group of 17 software developers, scientists, programmers and authors gathered at a ski lodge southeast of Salt Lake City, Utah, in search of a solution to mounting concerns about the software development industry.

Nicknamed “the Snowbird 17,” they gathered to see if representatives of their different disciplines could agree on a path forward. And much to their surprise, they did.

In a 2006 interview, Robert “Uncle Bob” Martin, one of the visionaries in attendance that weekend, said the biggest disagreement of the weekend was about what it should be called.

“The formal name of the weekend retreat was ‘Lightweight Methods Summit,’ but no one liked the term ‘lightweight.”

After proposing and discussing a number of alternative names, they used a show of hands to adopt one of the other attendee’s suggestions of using the word “agile.” It was unanimous. And it was also the only actual vote held during the weekend meeting.

By the time the weekend was over, the document officially known as ‘The Manifesto for Agile Software Development,’ emerged and outlined a detailed path for software developers to improve methodologies and respond to inefficiencies of traditional development processes.

According to Martin, the Manifesto itself came into being on the first day of the meeting guided by four simple values. On the second day, the group expanded the scope to include a set of 12 principles, which Martin said were negotiated by email afterward—a process that apparently took several months.

Although the original document specifically focused on helping software developers work faster and more efficiently, the signers couldn’t have imagined how quickly their ideas would spread beyond the software industry to have an enormous impact on the wider development industry and beyond.

At the time the Manifesto was written, various agile-like principles had been around for nearly 30 years, but it was frustration with the traditional—and often cumbersome—development processes of the 1990s that led to the retreat.

As personal computing gained in popularity, it required product and software development to undergo significant changes, and the general consensus was that the status quo was no longer working. The lag time between business needs and developed solutions was averaging three years, and the existing processes were considered by many to be “unwieldy, unsatisfactory and overburdened with documentation and oversight.”

According to Jim Hightower, another one of the Manifesto’s original authors, the document was designed to help speed up the process by encouraging work practices that focus more directly on the user.

“The values and principles allow teams to be adaptive, to respond quickly and effectively to change, and to be in a state of constant reimagination underpinned by frequent customer feedback,” he said.

In a historical narrative archived at agilemanifesto.org, Hightower said some corporate bureaucrats tend to be scared of agile approaches—specifically those “that are happy pushing process for process’ sake versus trying to do the best for customers while delivering something timely and tangible as promised.”

“We wanted to restore a balance,” he wrote. “We embraced modeling, but not in order to file some diagram in a dusty corporate repository. We embraced documentation, but not hundreds of pages of never-maintained and rarely used tomes. We planned, but recognized the limits of planning in a turbulent environment.”

When used correctly, many believe the Manifesto remains as relevant today as it was when first written 20 years ago and can be a valuable tool not only for developers, but also for diverse groups such as PR and marketing teams, product managers, software coders, and others.

But that hasn’t stopped some critics from voicing their concerns.

In an article published five years ago on TechBeacon.com celebrating the 15th anniversary of the Manifesto, Malcolm Isaacs, a senior researcher at Micro Focus, described the irony of a document that embraces change but is reluctant to change itself.

Isaacs wrote, “In fact, the Agile Manifesto seems to be the only thing in the software development industry that has not changed at all since the time of its inception.”

Philippe Kruchten, a prominent Canadian software engineer, has likened the agile movement to an awkward teenager: “very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant.”

But despite his criticism, Kruchten said he also sees great potential in the timeless document.

“I have no doubts that it will mature further, become more open to the outside world, more reflective, and therefore, more effective.”

Author

Author:

Other Resources in this Series

Most Recent

Article

Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.
Prism photo: Product management Lessons from Pink Floyd
Article

Product Management Lessons from Pink Floyd: a Lighthearted Look into Their Epic Music and Unlikely Product Expertise

Few people (actually, no one!) spontaneously associate product management with Pink Floyd, but if you look closely, you can find good examples of best product management practices in their journey, as I hope to reveal...
Creating a product roadmap: what should you include
Article

A Guide to Product Roadmaps: How to Build One That Works

A product roadmap is a frequent request from the sales force and others in the company. ‘What’s coming in the next release and the ones after that?’ Long buying cycles common with strategic products often...
Dry erase board with product roadmap drawn on it
Article

How to Build a Brilliant Visual Product Roadmap

Building roadmaps is a crucial part of a product manager’s job. Yet most product managers still use outdated tools for roadmapping—Excel, PowerPoint, wikis, etc. The good news is that there’s a better way. Executives have...
Product Datasheet
Article

How to Write a Kick-Butt Product Datasheet

If your datasheet passes the all-important skimming test, it's more likely that buyers will read it in detail. Here are 10 tips to help you write a datasheet that buyers actually read.

OTHER ArticleS

Article

Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.
Prism photo: Product management Lessons from Pink Floyd
Article

Product Management Lessons from Pink Floyd: a Lighthearted Look into Their Epic Music and Unlikely Product Expertise

Few people (actually, no one!) spontaneously associate product management with Pink Floyd, but if you look closely, you can find good examples of best product management practices in their journey, as I hope to reveal...

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

Subscribe

Subscribe