As soon as I heard the term applied to software development and considering the 17 individuals who codified, ratified, and released the Agile Manifesto in February, 2001, I instinctively knew the trail the Agile Manifesto's authors were blazing was the right path. I knew that because Agile wasn't conjured out of whole cloth. Many of the practices we refer to as Agile pre-date Agile. In spite of being so difficult to implement and the nay-saying, I've always regarded the journey, along with the pain of experience, to be worth it because that's the necessary feedback we need to improve. A common refrain for a typical team may be “Our releases are too buggy; we need to reduce defects.” How do we do that? The answer lies in the heart of Agile. Let's go find it.

If you're not familiar with the Agile Manifesto or if it has been a while since you've read it, take some time to review: www.agilemanifesto.org. One page that's often overlooked is Jim Highsmith's history page: www.agilemanifesto.org/history.html. Jim is one of the 17 Agile authors. As it turns out, that history page has been an easter egg of sorts, hiding in plain sight, for it gives us an inkling of what lies in Agile's heart.

Doesn't the Agile Manifesto Already Answer the Question?

No, it doesn't. The Manifesto is the by-product of, among other things, Agile practices. That's how we know Agile wasn't conjured out of whole cloth. Somewhere between various practices being created and implemented and the formal Manifesto, something was brought to bear. Therefore, although we can look to the Manifesto to know what Agile is, we must peel-back the onion to get to the root of what lies at the heart of Agile.

The Manifesto's Values

There are four values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The context for these four values is found in the following affirmation [emphasis added]:

We are uncovering better ways of developing software by doing it and helping others do it.

Agility is an active, not a passive thing. Agility is practiced by being it, not talking about it. The principle concern is quality software through better means. The work itself is the only input the arbiter of quality should need to consider because values are in the work itself. Therefore, the only lens to view quality through is the work.

The four values on the left in the Manifest could be distilled into four words:

  • Cooperation
  • Accountability
  • Engagement
  • Agility

The Manifesto closes with:

While there is value in the items on the right, we value the items on the left more.

The closing statement is pragmatism in action. If a process must be followed because of some law, rule, or regulation, then it must be followed. It's often necessary for software development to seek better ways for its Agile environment to accommodate processes, tools, plans, or other terms and conditions that, historically, have been carried out in a non-Agile manner. Despite best efforts, tension may rise between the values on the left and the right. How to deal with that tension is often a make-or-break proposition for Agile's success in an organization. These values are based on what lies at the heart of Agile. Get your goggles on, we have more onion peeling to do!

The Manifesto's Principles

The Manifesto's principles are found here: http://agilemanifesto.org/principles.html. From a historical perspective, the Agile Manifesto was released after the February 2001 meetings at the Snowbird Ski Resort in Salt Lake City, UT. The 12 principles were published soon thereafter. The principles are very important in that they transcend specific practices. Although the principles are important, they aren't relevant for this inquiry into what lies at the heart of Agile because the principles are backstopped by the values. Their essence is that matter what we specifically do in the Agile space, we must always transparently inspect and adapt our work. And that process involves a constant inquiry into whether what we're doing is consistent with Agile Principles and Values.

It's worth mentioning that this question of what lies at the heart of Agile may either be simple or impossible. It just depends on where you begin your journey. In my experience, most Agile advocacy content begins with a tool. In such cases, the advocacy is substantively product advertising. “Use our tool and your Agile implementation will be smooth” is often the refrain. If you've settled on Agile, jumping from tool to tool won't work because no tool can ever be the thing that tells you what Agile is and makes you understand it better. For sure, a tool may help you better apply Agile. But when things go wrong and you must diagnose your “Agile dysfunction,” no tool is going to help you. Your values and your commitment to them are your only fuel source. What is that “Agile dysfunction” you're dealing with? Why aren't things working? We can answer that question by analogy and looking to what happened at Snowbird in 2001.

The “Deeper Theme”

I'm closing this installment with what was mentioned at the outset, the history page: http://agilemanifesto.org/history.html. I must confess that for many years, I never read this page. But once I did, it all became clear. There's discussion of a "deeper theme that drives many, but not all…". There's further discussion on the Snowbird environment being one built on trust, on respect-centered values within which people wanted to work. Finally, it all boiled down to Agile being about “mushy stuff of values and culture.” Channeling Hamilton, the history page is a contemporaneous account by one who was in the room when it happened!

What Lies at the Heart of Agile?

Among other things, egalitarianism, the notion of equality is at the heart of Agile. At Snowbird, there were 17 supremely talented and internationally recognized thought leaders who, no doubt, disagreed on many things while at the same time, agreed on many things. To check most of the differences and ego for the benefit of what the group set out to do, ultimately for the benefit of the whole world was egalitarianism through a “deliberative assembly” or sorts. In Denmark, the parliament is called the Folketing (people's thing). The “things” were deliberative assemblies, such as a tribal council. While there was structure and a hierarchy, any man was free to plead his matter and be heard. In any conflict resolution, there's give and take. Nobody gets everything. But if not done well, everybody gets nothing. In this regard, it should almost be instinctual to cooperate. But it's often difficult because egos get involved, and that's why being Agile is so difficult. Individually, each must live the values so that collectively, the group can. There's plenty of room for compromise, but that compromise must be subject to Agile values. Agile requires active cooperation, active accountability, and active engagement. Anything less and you'll be introducing dysfunction, the seeds of technical debt, into your organization.

If you're in a decision-making capacity and if you're either seeking to implement Agile or address some Agile dysfunction, you'd be well served to look at history. Look at the history of how Agile came to be. And from there, look to how the basis of that is rooted in the earliest democratic practices in recorded history in order to understand what Agile actually is and to understand what lies at the heart of Agile. If your organization runs its software development operation like a top-down hierarchy, Agile won't work. Just as you can't fly a car, you can't waterfall Agile.