The Agile Manifesto, Revisited
The Agile Manifesto is almost twenty years old, and Agile is now everywhere, though often practiced with varying degrees of fidelity to the original intent of the Manifesto. This article considers the Agile Manifesto in the context of modern Agile process and the ways we apply and misapply Agile concepts.
Agile Manifesto
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.
The Agile Manifesto Explained
“We are uncovering better ways of developing software by doing it and helping others do it.”
This quote starts the Agile Manifesto and encapsulates several key concepts:
Uncovering better ways of developing software
Agile was created by software developers and architects so there is an inherent software bias, however Agile principles can apply to almost any industry or setting. At its essence, however, it is about identifying better ways of doing the work we do.
By doing it
These are best practices learned over time by professionals in a real world setting. This isn’t a theory, but rather a collection of innovations, performed in real time. This is something we do.
And helping others do it
Agile is a collaborative process, and part of it is to help and support others, as they in turn help and support you. The Agile manifesto is informed by the creators’ experience leading and guiding others in collaborative environments.
Next, let’s look at the four core principles of the Agile Manifesto.
1. Individuals and interactions over processes and tools
What is the benefit of focusing on individuals and interactions as a primary way of working, over processes and tools?
According to conventional wisdom, processes and tools are person-agnostic, meaning that regardless of who works on a project, those will stay consistent. If someone leaves the company, it appears as processes and tools stay the same and are thus a safer bet than depending on individuals and interactions. Individuals leave the company, interactions are nebulous and ephemeral and rarely documented in a way that can be shared later. Then why focus on them as opposed to the safe process/tool approaches of the past?
Because Agile is about agility “the ability to move quickly and easily.” How quick and easy is it to change course or incorporate new learnings in an environment centered around specific processes or tools? Think back on all those times you tried to change an established course in a traditional environment and you will agree it is not easy. If we want agility, if we want to be able to move quickly and easily, we need a more lightweight methodology and less dependence on tools to define how we work. By shifting the focus to individuals and their interactions, we put our work at the heart of where work happens, in the minds and conversations of our team members. Humans are more easily able to transcend rote ways of thinking if there is an inherent flexibility to their ability to understand and problem solve.
In Star Trek, the computer technology on the Enterprise had advanced to the degree where problem solving often depended on simply knowing what questions or direction to give the ship’s computer. Solutions to their problems were often only limited by their imaginations and creativity. We’re not quite there yet, but team members unencumbered by limitations imposed by onerous processes or restrictive technologies, have more freedom to think outside the box and conceive of truly innovative solutions.
2. Working software over comprehensive documentation
The traditional software engineering approach usually involved extensive documentation before, during, and after a project. After all, this is computer engineering, and engineering has been a complex science requiring extensive planning and coordination. This document-heavy approach delivers a predictable solution that has maximum buy in from everyone who worked on and/or approved the requirements documentation.
The Agile manifesto argues that this methodology, while proven and valid in some cases, does not support agility. In a monolithic, documented application, there is no room to pivot, no touch points to validate what has been done during the development, so you never know if you are on the right track until you complete the entire application and release it to users.
By putting the focus on working software over documentation, Agile encourages getting work done and letting that work speak for itself, both as a reflection of the needs of your users and as a set of working documentation. We are fortunate enough to live in a time where software development technology has become much more nimble, and there are myriad choices for implementing your solutions that allow you to change tack and quickly re-code if necessary. This supports the working code principle; rather than take time to write documentation, you can code it just as quickly and find out much faster if it delivers value to the user.
When we consider our design solutions as hypotheses to test rather than definitive answers to implement, we accept that we may be wrong and need to re-code. This is at odds with up front planning and documentation. We should only be planning our next experiment while considering what might come after depending on the results. Getting working code into the hands of our users should be our primary goal at all times, so that we can get the validation for our hypotheses in a real world scenario.
Even high fidelity prototypes, while valuable in uncovering many kinds of issues before development, usually can’t replicate the experience of working code. Your working code becomes, in essence, a working prototype. Prototypes are often wrong, and working prototypes need to be re-coded. This requires working in the lightest way possible, with nimble technology that allows for quick rework and no onerous documentation requirements. The working code/feature set is our documentation for the project, created in the act of coding and validating each design hypothesis while only keeping what delivers value to the user.
3. Customer collaboration over contract negotiation
A classic pitfall of software development, based on a contract approach of a set number of deliverables pegged to a certain date, is Scope Creep; the inevitable adjustments and additions to a project, often driven by the customer seeing early releases of the software “Wait, that doesn’t make sense on that page now that I see it there, what if we created a new section for it and moved over parts of these other two pages…”. Contracts are meant to guard against this, but actually force us to either accept the scope creep to make the customer happy at the risk of missing deadlines, or stand strong against scope creep and deliver what was promised, on time, to an unhappy customer who didn’t get what they realized they wanted over the course of the project.
Agile suggests flipping the script on this dynamic. Instead of using a contract as a strategic weapon to contain the desires of the customer, we create a new kind of relationship with them based on the cadence and goals of Agile. We effectively say to the customer “We accept that none of us knows exactly what you need for your solution and we will discover that in the process of creating it. We are asking you to take a journey with us through our Agile process where we iterate and learn, incrementally completing your solution with proven features. We can’t say exactly how long it will take or exactly what it will look like in the end, however we do know that our process will get us to a better solution and will actually take less time with more success than the inevitable rework and disappointment of a traditional contract based project .”
This is asking customers to take a leap of faith into a new way of working, one that is far less predictable than waterfall methods. However, anyone who has been through waterfall project knows that there are usually delays to rework or add additional functionality and/or a customer unhappy with the final result. We need to help our customers realize this new approach not only validates features every step of the way but also keeps up with the pace of waterfall development when those negative aspects are factored in. Customer buy-in and faith in the process is essential for the success of Agile Design.
4. Responding to change over following a plan
At the heart of the Agile methodology is the ability to respond to change, which is about learning; what did our experiment teach us? Are there factors we didn’t consider? What new information do we have to inform our decisions?
So what is the change we are responding to? It is when user validation gives us either a no or maybe answer to the question our hypothesis is posing (typically, does this feature deliver the intended value to the user?). When our experiments are proven false or maybe false (meaning that there is some potential for value but also impediments that need to be resolved) we need to reconsider our design direction. Along with the no/maybe will typically be some qualitative feedback from users about why the hypothesis feature does not deliver the intended value. This is the data you can use to devise other solutions. In this way, by iteratively presenting responses to change or modifications to your solution that intend to resolve issues raised by users, you will steer your solution closer to delivering optimal value.
Agility is about moving quickly and easily, including the ability to change direction at will. There is no way to follow a plan (another way of saying waterfall methodology) when the process, by its very nature, is a process of discovery and emergent design. Not only do we embrace change, but we actively pursue it by validating our hypotheses with equal acceptance of the results whether it’s a yes, no or maybe. We could even learn to love the no answers sometimes; when a user completely invalidates a design idea, you can enjoy the fact that you didn’t spend six months building it only to find that out much later. You should want to get to no because that’s often the only way to get to yes.
Principles behind the Agile Manifesto
We follow these principles:
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 to the shorter timescale.
Business people and developers must 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 to 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.
