The agile manifesto (www.agilemanifesto.org) was created by a group of very bright and experienced people. However, these people all came from the supplier side of software development, something that’s evident already in the third of the four value statements:
Customer collaboration over contract negotiation
– implicitly saying that “we” are not the customers.
To reap the largest benefits of agile philosophies, the customer side of projects also need to work in an agile manner. This involves more than providing the developer teams with a Product Owner. The customer side of a project doesn’t only have to work with the developers, but also their own organization and other stakeholders. Most importantly, the customer side of a project has to figure out what goals the product should reach in order to create real value to the stakeholders.
So, I wonder, what would the agile manifesto have looked like if it was created by customers instead of suppliers?
Here’s my take.
We are uncovering better ways of running software projects 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
- Delivering stakeholder value over completing features
- Collaboration with suppliers and organization over contract negotiation
- Responding to change over following a plan
(Note: In the following, I’ve left the original principles in so that you can easily see the similarities and the differences.)
We follow these principles:
There is no use in doing things right if we don’t do the right things. We must continuously work with our organization and our end users to figure out what the right things are.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Our highest priority is to create value for our stakeholders through early and continuous delivery of software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Welcome changing requirements, even late in the project. Agile processes harness change for our organization’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Deliver valuable solutions 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.
We must work together with the stakeholders and the developers continuously throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
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.
The most efficient and effective method of communication is talking face-to-face while visualizing the subject on paper or whiteboard. Use other means only when their added value is greater than their added costs.
- Working software is the primary measure of progress.
Value realized by the stakeholders 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.
Agile processes promote sustainable development. The sponsors, stakeholders and developers should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
Continuous attention to high technical quality enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
The best solutions emerge from self-organizing teams with clear goals.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
At regular intervals, all parties reflect on how to become more effective, then tune and adjust their behavior accordingly.
I have stayed close to the original values and principles – perhaps too close. Staying close to the original may be of value – it sort of gives the customer and supplier side a common ground. But it may also mean that I miss something important. However, it’s not my intention here to write a totally new manifesto (how could I?), but rather play around with the “what if…” and maybe learn something valuable about the differences between developer and customer perspectives.
What do you think?
(This article can also be found in Norwegian at Sterk Blanding, Steria Norway’s blog. Thanks to my reviewers Johannes, Eli and Simen for improving this article.)