Happy anniversary, Agile Manifesto! It’s hard to believe you were created 20 years ago this month, in a ski lodge in Snowbird, Utah. The world was a very different place, then, wasn’t it?
Enron was #7 on the Fortune 500 list. Python, PHP, and Lisp were popular programming languages. Apple was getting ready to introduce the first iPod, and Microsoft would later premiere the Xbox. “Harry Potter and the Sorcerer’s Stone” would become that year’s most popular movie. Wikipedia was about to launch.
Like many great inventions, Agile Manifesto, you were born of necessity. Your founders were frustrated with the way software was being developed back then. It was a linear, top-down, bureaucratic, waterfall process, saturated with documentation. The inherent conflict between the rigid, hierarchical power structures inside most corporations and the adaptive, fast-moving, ever-evolving world of software was a constant source of frustration. The development process often omitted the customer’s point of view. And there wasn’t much flexibility to adapt to inevitable changes before the software shipped. (Microsoft Windows XP, released the same year, literally shipped to customers on millions of CD-ROMs!)
A Better Way to Build Software
So when your developer founders got together for a week of skiing, eating, talking, debating, and writing in February of 2001, they brought with them a bunch of ideas (some say Agile’s origins actually date back to 1968.) Their hope was to suggest a better way of developing software, one they could use themselves and share with others. They wanted to capture a set of working agreements based on trust, respect, and collaboration. Rather than simply following fixed requirements, timelines, and contracts, they aspired to deliver working products that would satisfy customers—in a working environment that they themselves would find rewarding.
Let’s revisit what they came up with, shall we?
* * * * * * * * * *
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.
* * * * * * * * * *
“We are uncovering better ways of developing software by doing it and helping others do it.” By using the present tense here, your founders baked collaboration and continuous improvement into the heart of your guidance. And unlike with traditional charters and constitutions, they position your beliefs not as absolutes, but as comparisons: “Individuals and interactions over processes and tools.” That speaks to your emphasis on adaptability and collaboration.
And let’s not forget your 12 principles. It’s interesting that over the last year many of us have had to re-think principle #6: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Because of the pandemic, many of us simply can’t be together in person: a face-to-face Zoom meeting is the best we can do. Yet even as the world changes at what feels like a steadily accelerating pace, these principles remain a compass for practicing agilists. The methodologies and frameworks may be different, but your common tenets hold us fast to what really matters.
How about your name? One interesting fact many people may not know about you, Agile Manifesto, is how you came by the name “Agile.” Apparently there was a lot of debate over what to call you. Some wanted to use the term “lightweight,” while others thought that had negative connotations; some wanted to use the word “adaptive.” In the end they decided on Agile, and they used it strictly as an adjective.
Look at You Now, Agile Manifesto
Today, “Agile” is very much a noun—and that too is a source of debate. You probably never would have guessed that you’d give birth to an entire industry of training, coaching, consulting, and tooling. You’ve been translated into more than 60 languages. People have even developed Agile Manifestos for non-software disciplines, including marketing and HR.
Other “management fads” like TQM and Six Sigma have come and gone, but you’re still going strong, Agile Manifesto. In fact some might say you’re just getting started. The fact that software has eaten the world certainly helped your growth. Research finds that eight in ten organizations have adopted or are planning to adopt Agile, and your tenets are endemic in some of the most successful companies in the world: from Amazon, Apple, and Google to Walmart, ExxonMobil, and Lockheed Martin. Many organizations climbing the NASDAQ charts in the last decade build software according to your tenets but don’t even call it Agile: according to some, this indicates you’ve crossed the chasm.
But don’t let the “industry” of Agile fool you, Agile Manifesto. Anyone who’s practiced Agile approaches can tell you that it’s not about the processes, titles, tools, or stickies on whiteboards. It’s about working together with trust and respect, building products with quality and empathy, and collaborating with responsiveness and transparency. As one of your founders, Jim Highsmith, described in your history:
“At the core, I believe Agile Methodologists are really about “mushy” stuff—about delivering good products to customers by operating in an environment that does more than talk about ‘people as our most important asset’ but actually ‘acts’ as if people were the most important, and lose the word ‘asset.’”
A Better Way of Working
SAFe itself is indebted to you, Agile Manifesto, for providing the foundation for a new, more effective way of working. We have 700,000 practitioners in 20,000 companies across the globe, and it’s likely no two of them are using SAFe in quite the same way. The ability to adapt a methodology like Agile or SAFe to make it effective for one’s own environment relies on strong principles. So this month, we want to celebrate you by diving into your tenets and principles with our community!
In the vein of continuous improvement that you established with your birth, Agile Manifesto, we invite the community to take this opportunity to look forward. How can we keep evolving your manifestation in our day-to-day work? How can we use your tenets to keep improving how we collaborate and build products that customers will value? What about you might need to change to accommodate our ever-changing world, or to expand your use outside of software? How might we invite more women and people of color to participate with you?
Here are a few ways we’re celebrating you, Agile Manifesto, over the month of February. We hope YOU, our community members, will join us in these discussions.
Agile20 Reflect Festival: A Journey from Waterfall, RUP, Lean-Agile to SAFe
February 10 // 9:00 AM MT // 16:00 GMT
This panel discussion, co-hosted by Radtac and the London SAFe Meetup, will feature Dean Leffingwell, co-creator and founder of SAFe. Dean will share his perspective on the Agile Manifesto and how it continues to influence his work in applying Lean-Agile methods at enterprise scale with SAFe. You’ll also get a chance to hear some of his memorable career experiences and lessons learned as an entrepreneur, CEO, methodologist, author, coach, and willing critics’ foil.
Applying the Agile Manifesto at Scale: A Panel Discussion
February 22 // 10:00 AM MT // 17:00 GMT
The Agile Manifesto is now 20 years old. So it’s fair to ask, given all the advancements in the last 20 years, Is the Agile Manifesto still relevant? Does the Agile Manifesto scale? Does it meet the needs of enterprises developing the biggest and most complex software and systems? In this panel discussion, five SAFe Fellows (Andrew Sales, Eric Willike, Inbar Oren, Michael Stump, and Robin Yeman) will address these questions and reflect on the vital role that the Agile Manifesto plays in SAFe and how it remains as relevant today as ever. The panel will also consider which principles of the Agile Manifesto require increased emphasis at scale, which ones require an expanded perspective, and what shortcomings need to be addressed.