What the Agile Manifesto Values Mean to Me
The Agile Manifesto reached its 20-year anniversary last year, a significant milestone. What follows are my ruminations about each of its four opening statements, also known as its 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
I’ve also added a bit of bonus content. Specifically, I’ve written four poems in a type of haiku style called senryū, where there is one poem for each of the agile values.
Individuals and interactions over processes and tools
senryū:
Nothing beats teamwork.
Striving to excel as one,
scarce need for process
What does this first value mean, in practice? The emphasis on caring about individuals, and the need to create space for and nurture the interactions that we have with each other, is something to be cherished. Few are the organizations that truly believe in this foundational concept — AND, fewer still are the cases where an organization’s walk matches its talk. It takes continuous effort by everyone to make sure that people truly do come first.
When it comes to processes and tools, there is a need for some process, and there is a need for some tools. One of the most common mistakes that organizations make, however, is to let the behavior of a tool dictate the way in which they work with each other (Jira is among the most common examplars of tools driving behaviors.). It’s also easy for many organizations to fall into the trap of creating another process in response to any problem or challenge that arises. Just as Agile practitioners use the term “just in time” or “the last responsible moment” when it comes to our approach to when to make business and technical decisions, we need to also strive to have a minimalist mindset when it comes to process — that is, “just enough process.”
Working software over comprehensive documentation
senryū:
There is fulfillment
in writing elegant code;
less so for tech specs
It is all too easy to misconstrue the intent of this statement. There is still a need to write some documentation; it’s more a question of emphasis, and the amount of effort we spend on one thing vs. another. Consider what happens on traditional (waterfall) software projects, where numerous documentation deliverables were written, before a single line of code was ever written. Furthermore, each of those documentation deliverables tends to go through a lengthy review and approval process.
To put it differently, let’s consider a business value perspective. What’s the business value of a requirements specification, for instance? Answer: the business value of a spec (or any similar document) is ZERO — it could be the greatest specification in the world, but there is nothing that a potential customer can do with a specification to solve an actual problem.
And this brings us to where we put the emphasis when it comes to agile software development — the iterative delivery of business value to customers, via working software. A key component of frequent delivery is keeping feedback loops as short as possible, such that we when we make a change to the product, we want to get a read from customers on what they think about the change quickly, so that we can course correct as necessary going forward.
To sum up, writing documentation in an agile context comes down to writing documentation that is “just-in-time,” and just detailed enough, to enable us to move forward. The level of detail that’s needed can certainly vary, depending on context. At the end of the day, it comes down to having shared understanding, about the why, what, who, when, and how of what we’re building.
Customer collaboration over contract negotiation
senryū:
Happy customer,
far more likely when involved
than arbitrating
Of the four values from the manifesto, the intent of this value might be a little less obvious than the other three. If we take “contract negotiation” at face value, one way to understand this statement is within the context of a consulting arrangement, where some or even all members of a team might be consultants, providing agile delivery services, and thus the customer in such an instance would often be the organization that retained the services of the consultants.
Let’s also think about this in a context that looks less like consulting, and let’s once again contrast agile with waterfall. In the latter (waterfall) case, customers negotiate requirements for a product, often in great detail, where the requirements are articulated in various written deliverables (and once again, it’s rare for any code to be written until after the completion of this negotiation phase), the end of which is often signaled by “requirements being frozen.” Also, importantly, on traditional projects, the level of direct customer involvement tends to drop off significantly once the actual development work has begun. Contrast the waterfall approach with agile, where the voice of the customer is intended to always be front and center, from beginning to end. One of the undesirable outcomes that the agile approach helps avoid is the dreaded “building the wrong thing.” There is nothing worse than investing a lot of time in something, only to discover, after it’s been released, that it really doesn’t meet a customer need.
Responding to change over following a plan
senryū:
Change for the better,
not for the sake of changing,
just enough planning
In “knowledge work,” which includes software development, the pace of change can be rapid. Thus the framers of the manifesto were recognizing the reality that it’s often necessary to pivot in the face of normal discovery, not to mention other factors, such as changes in market conditions.
To be clear, what this value is NOT intended to suggest is that there is no planning in agile. In fact, the reverse is true — the level of “planning discipline” actually is high with agile. To put it differently, planning is not just a phase at the front end of a project. In agile, planning is continuous, and also needs to account for different planning horizons. If we take Scrum for example, a short planning horizon is the conversation that takes place during a Daily Standup (Daily Scrum), where team members might make an adjustment to their plan for the next 24 or hours of so, based on that conversation. During Sprint Planning, the planning horizon is the length of the Sprint timebox. For Backlog Refinement, the planning horizon can vary, anywhere from the next Sprint, to perhaps the next several Sprints (or perhaps even longer term, depending on team context).
Conclusion
I hope you’ve found this brief walk-through of the four values from the Agile Manifesto to be helpful. There is plenty more than can — and indeed, has — been said on this topic. I will leave you with this quote by Jason Balaski: “The role of a change agent is to create flow — not control.” Let’s strive to be change agents that consistently model the agile values.
