Despite loving it, I am uncomfortable with The Agile Manifesto. I get that it has come from the software development world. I get that it sought to drive better ways to create product and to create better product. I understand that it advocated for a new way of working not bogged down by processes, tools, contract negotiation and following a plan. I applaud that it advocated for individuals and interactions and customer collaboration and responding to change. What doesn’t work for me is that it makes a whole bunch of assumptions based on the software development world, that just aren’t right for the world in which Agile could now be applicable. So what could an Agile Manifesto for output that’s broader than just software development look like?

First to the assumptions. “Individuals and interactions over processes and tools” is the first statement in The Agile Manifesto. This has of course been the most controversial of all the manifesto’s statements. It was never the intention of the authors of the manifesto to throw the baby out with the bath water. The manifesto explicitly states that “while there is value in the items on the right, we value the items on the left more.” So, while processes and tools were seen as having value, individuals and interactions were seen as having more value. The assumptions in this statement are threefold:

1. that processes and tools may not necessarily support the efforts of individuals
2. that processes may be unwieldy, or that they contain ambiguity
3. that tools introduce overhead and work for the sake of work, rather than contributing to working software, or output.

Agile doesn’t dismiss process. The use of a Kanban board, which at its most rudimentary level contains a “To Do”, “In Progress” and “Done” flow, is in fact a process. Put simply, it is a defined and agreed upon workflow process that creates a common understanding of how work is going to get to done.

Is there a way that the value of individuals and interactions could be articulated so as not to fuel critics of Agile who imagine that an Agile workplace is staffed by individuals doing their own thing, in the absence of a common understanding or common process?

With respect to tools, Agile seeks to disclose where the use of a tool serves no useful purpose in contributing to the output of a team. We know though, that in both the software world and beyond, there are a whole bunch of tools that are incredibly useful in creating more fit for purpose output. Using a Wiki as an information sharing tool has saved me hours of time. Google Analytics is a tool that has provided insight into how customers are using digital products, in a way that conversations about how we think customers are using products haven’t. Automation testing has helped fulfil on the Agile Principle of “simplicity – the art of maximising the amount of work not done”. Individuals and Interactions drive the best use of these tools, but tools certainly provide value. The Agile Manifesto was written in the pre app world, does it’s deprecation of tools over people and conversation align with our today environment?

How about “Working software over contract negotiation”? This statement is loaded with the frustration of software developers dying to get cracking on writing code, but being hampered by extended contract negotiation. We know of course that what this statement is really trying to convey is that Agile measures the value of what has been delivered in terms of the actual output. So, how could we remove the software development assumption from this statement, to ensure the message of delivering value through output is stated loud and clear and that the time involved in discussions that are not effective at defining what needs to be built, is flagged as waste?

The final item in the Agile Manifesto is “Responding to change over following a plan”. This statement has been used by critics of Agile to suggest that Agile doesn’t believe in planning. This couldn’t be further from the truth, as breaking features down into user stories with defined Acceptance Criteria is a more useful form of planning than typical Business Requirements Documents. We know of course that this manifesto item refers to acknowledging that as we learn more through developing a product, testing it in market and validating how users interact with it, we value adapting future iterations over sticking to the planned rollout. So how can we reflect the value of adaptive planning, pivoting, and planning only as much as you need, into an updated Agile Manifesto?

In my organisation we’ve embarked on a task to adapt the Agile Manifesto not just for a broader base than software developers, but also to remove some of the ambiguity in the manifesto and embed lean startup principles that closely align with Agile practice. This adaptation was the brainchild of my colleague Tim Hetherington, and to be perfectly honest I was a little sceptical about it at first. I didn’t mind explaining stuff to critics of the manifesto because I always found this to be an interesting conversation that lead to unpacking the manifesto’s values. But when Tim started articulating some reinterpreted manifesto principles, I was quickly convinced. Tim worked with Megan Capicchiano on the new manifesto statements below. It was my job to articulate each statement into a set of value dot points to describe what this looked like in day to day behaviour.

We’d love your feedback. Does this stuff resonate for non-software developers as well as software developers? Have we lost the essence of the original manifesto, or reinterpreted it for today? Are these principles accessible enough for organisations to accept? Could these new principles create cultural change in your organisation? Feel free to comment.

1. People and conversations over ambiguity and assumptions

• We seek to understand requirements, resolve problems and collaborate through conversations, not emails or IM.
• We recognise that conversation is the most effective way to disclose assumptions, clear ambiguity, share information and create common understanding.
• We speak up when we perceive a simpler way of doing something.

2. Partnership collaboration over hierarchy and silos

• We create partnerships between groups to work on customer centric solutions.
• We use collaboration as a way of ensuring we are delivering the right outputs.
• We commit to both stakeholders and delivery teams being involved for the duration of projects.
• We strive to achieve organisation-wide strategic solutions that deliver shared value, rather than specific purpose implementations.
• We trust individuals tasked with completing work, regardless of where they sit in the organisation’s hierarchy.

3. Quality and value of work over quantity

• We recognise that limiting the amount of work in progress is the most efficient way for us to manage throughput.
• We use a limited work in progress approach to prioritise delivery of the most valuable work within resource availability.
• We ensure that we deliver the desired quality output by limiting work in progress and reviewing progress with stakeholders along the way.
• We analyse our output to ensure our productivity and quality leads to continual improvement.

4. Delivering iterative business value over big bang roll-outs

• We deliver incrementally to reduce the risk of big bang delivery that no longer aligns with customer expectations, current technology or market conditions.
• We use iterative delivery to validate our assumptions, learn, and recalibrate as required.
• We iterate to quickly deliver a minimum viable product, knowing that what we learn from this will ultimately create the most customer centric solution.

5. Continuous planning over inflexible planning

• We prioritise planning the most important components, so we can deliver them first.
• We see high value in targeted planning of the components being delivered first.
• We accept that planning of subsequent features needs to happen once we have customer response to rollout of initial components
• We see less value in planning components that have less certainty of being developed.