The History, Spirit
Isn’t “agile” just the latest fad? Isn’t “agile” a product development methodology? How does “agile” apply to organizations? These are just a few of the many legitimate questions regarding the philosophy that has come to be known as “Agile,” and the confusion is understandable. There are different agile methodologies, (e.g., Scrum; SAFe; etc.). There are methodologies pretending to be “Agile” (i.e., traditional, waterfall methodologies given an agile coat of paint). And there are “Agile” zealots, each with their own discipleship, preaching their gospel of agile as a one-size-fits-all fix for whatever ails you.
Like every new thing that is blindly adopted on a broad scale, “Agile” risks the same danger of being relegated to “fad status.” Similarly, “organizational agility” risks the danger of being management’s next silver bullet. And that would be a shame. Frankly, the risk of either of these occurring is a function of the adopter’s motivation, depth of commitment and strength of leadership — all of the same things that differentiate legitimate change from manipulation.
And it is true that “Agile’s” roots are in product development; specifically, software development. However, with successful use over time, Agile’s philosophy and principles have been found to have broader applicability. The “Agile philosophy ” is a legitimate and proven philosophy that is applicable not only to how you do your work, but also to how you govern the conduct of your work — yes, “organizational agility” is a legitimate thing.
While “agile” may seem like a recent thing, it really has a long history that goes back to the late 1990s/early 2000s.
The History of “Agile”
In the 12-18 months leading up to August 2001, a wide range of publications — Software Development, IEEE Software, Cutter IT Journal, Software Testing and Quality Engineering, and even The Economist — had published articles on what Martin Fowler called the New Methodology. These professional journals and articles reflected a growing interest in these new approaches to software development. At the time, they were known by a variety of names: Light Methodology; Extreme Programming, or XP; Crystal Methodologies; Adaptive Software Development; Feature-Driven Development; and Dynamic Systems Development Methodology among them. (agilityIRL’s own Jim Ruprecht co-authored one of these articles, “Light Methodologies: It’s Like Déjà vu All Over Again,” published in the November 2000 issue of the Cutter IT Journal, Volume 13, Number 11.) In addition to these “named” methodologies, scores of organizations had developed their own “lighter” approach to developing software.
Then, in early 2001, this soup of new wave methodologies achieved critical mass and coalesced under the name, “Agile.”
The Agile Alliance & Manifesto
It was February 11–13, 2001, at The Lodge at Snowbird ski resort in the Wasatch Mountains of Utah. Seventeen of the movement’s thought leaders met to talk, ski, relax and try to find common ground. A bigger gathering of organizational anarchists would be hard to find.
This was the genesis of what became the Agile Software Development Alliance, and what emerged from this meeting was more than symbolic. The Manifesto for Agile Software Development, was developed, signed by all participants, and published by Martin Fowler and Jim Highsmith in August 2001.
The manifesto called out the purpose and principles of agile software development.
The Purpose of Agile
We are uncovering better ways of developing software by doing it and helping others do it. We 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.
Agility is all about trusting in one’s ability to respond to unpredictable events more than trusting in one’s ability to plan ahead for them. The underlying principles include:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
- Business people and developers work together daily throughout the project.
- Build projects around motivated individuals, give them the environment and support they need and trust them to get the job done.
- The most efficient and effective method of conveying information with and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximizing the amount of work not done — is essential.
- The best architectures, requirements and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
“Agile” As a Philosophy
Although the Agile Manifesto is in the context of software development, at its core is the notion that facilitating change is more effective than attempting to prevent it. At its very outset the Manifesto states,
Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability to respond to unpredictable events; it’s more important than trusting in your ability to plan for disaster.
There is a point of diminishing returns in trying to predict and prepare for everything, but not so of your ability to sense, respond and adapt. This is because your ability to sense, respond and adapt is stronger than your ability to predict and prepare.
Further, the Agile Manifesto goes on to acknowledge a deeper theme at work — the teamwork philosophy underlying Agile:
We all enjoy working with people who share compatible goals and values based on mutual trust and respect, promoting collaborative, people-focused organizational models, and building the types of professional communities in which we want to work.
The purpose and principles that underlie the Agile software movement also apply to those many facets of organizational life beyond just software development, and it is this larger concept that constitutes the “agile philosophy.” It is a philosophy that applies to processes, products, services, individuals, teams, and organizations of any kind, any size, or at any station in some larger hierarchy.
We’re agilityIRL and we’re uniquely positioned to help you evaluate the value of adopting an agile approach in your product development — whatever your product might be — and/or embracing the agile philosophy in how you lead and manage your organization.
We can say that we are uniquely positioned to do this because we’ve been in your shoes. Our experience isn’t limited to academia or career consulting; we’ve done these things, multiple times, in real life.
If you’d like to learn more about our reality-based approach to creating and mastering process agility, just click here.
If you’d like to learn more about our reality-based approach for achieving organizational agility, just click here.
Or, if you’d rather just chat with us to learn more, we hope you won’t hesitate to contact us.