Since the creation of the Manifesto for Agile Software Development back in 2001, its values and principles have proven themselves to apply way beyond software development. So at the Agile Business Consortium, we have adapted these agile tenets, ensuring we remain true to the philosophy of the original thought leaders.
.We use these principles as guidelines for agile delivery in our Framework for Business Agility.
We are building on the original manifesto by uncovering better ways of developing solutions to business problems and opportunities. Doing agile is a crucial part of an agile organisation, next to, of course, being agile and delivering value. Through this work, we continue to value:
- Individuals and interactions over processes and tools
- Working solutions over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
While we value the items on the right, we value the items on the left more.
Changing the word ‘software’ in the second of the value statements to ‘solutions’, supports the idea that, if we are to focus on delivering value rather than delivering a product (such as a software application), it is often vital to think in terms of entire solutions, of which individual products or services are only a part.
A product does not realise value unless it is used for its intended purpose. A hammer, a nail, and a picture are all products, and they have a defined value because you can buy, sell, or exchange them. However, in the context of making a room more pleasant to live in, they have no value until they are combined to deliver a solution.
For example, if it is determined that a picture on a wall will make a room more pleasant to live in, then that defines a solution. The solution comprises three products - a picture, a nail and a hammer. Individually, none of the products will make the room more pleasant. The picture needs to be on the wall, which requires the nail to hang it on, which, in turn, requires the hammer to drive it into the wall.
The refined value statements are explained below.
Individuals and Interactions over Processes and Tools
In an agile environment, great emphasis is placed on the individual in the context of a wider organisation. Every individual is expected to be ready, willing, able, and empowered to play their part in an endeavour, carrying out their role with competence and professionalism.
Being empowered means those most closely involved in the work who are both capable and willing, being given the authority and responsibility by those leading or managing such an endeavour.
Every contributor is expected to work collaboratively with everybody else within clearly defined boundaries of empowerment, using their knowledge, experience, and judgement to shape an outcome that best meets the need of their customer and their sponsoring business.
By boundaries of empowerment, we mean the degree of empowerment that is in effect in a given circumstance — how much authority and responsibility are delegated by a leader or manager to an individual or a team, and how much freedom they have to operate independently.
In an agile project, for example, boundaries of empowerment are typically defined by the project leadership roles retaining powers associated with the strategic direction of the project, while self-organising project team members have the power to deal tactically with the details of what needs to be done, and to work out the best way of achieving it.
Processes and tools of course play an essential part in any structured endeavour, but much less emphasis is placed on these in an agile environment. Agile processes need to be light-touch and serve to guide and support rather than dictate what individuals and teams should do and how they should do it.
The assumption is that those carrying out the work are best placed to understand and manage the details of it. Contributors typically find working this way more enjoyable, and the broader organisation benefits from the enhanced productivity that stems from clearly focused, appropriately empowered, self-organising teams.
Working Solutions over Comprehensive Documentation
Changing a single word: ‘software’, to ‘solutions’ elevates the original value statement from the narrow context of delivering a software product into the broader context of business solutions.
The main message behind this value is to break the illusion of security and stability that comes from document-driven, predictive processes. Less agile approaches attempt to specify every detail of requirements, solution design, plans, etc., in documents that must be ‘signed off’ by stakeholders before work is allowed to progress. This is now widely accepted as wasteful in terms of time and effort, and ineffective as the basis of governance and control. This is especially true in a volatile, uncertain, complex and ambiguous (VUCA) world, where such documents are likely to be outdated even before they are signed off.
If they add value, high-level versions of documents can be created early on to help frame the solution's development and delivery and to support governance. However, it is essential to avoid getting into detail, which often ends up being a burden rather than an asset to the work or its intended outcome.
In the spirit of transparency, it is vital that any documents or other information sources created or used to shape or carry out the work are visible and understood by all, because failure to achieve such clarity and shared understanding will likely lead to poor decisions and poor results.
Customer Collaboration over Contract Negotiation
This value encourages those creating solutions and their customer community to always work collaboratively and to focus on valuable business outcomes rather than just material outputs.
For clarity, a customer is defined as any individual or organisation who is intended to benefit from the work of the project – i.e. anybody who will, buy, use or in any way consume the products and services being created, enhanced or changed.
Collaboration from the earliest stages of an endeavour leads to early insights and innovation around business problems and opportunities, a clear understanding of potential solutions, and a clear focus on the early delivery of customer value.
Typical commercial contracts often assume that a traditional sequential or ‘waterfall’ process underpins development of a product or service — one which relies on extensive and detailed up-front analysis and design work — and, accordingly, ‘a fixed price for a fixed specification’ is often the standard for project contracts.
Agile ways of working emphasise collaboration and the ability to respond to changing needs; therefore, contracts need to reflect this. It is important that we think beyond formal contracts that govern relationships between legal entities such as companies, to include any document that needs to be ‘signed off’. Signing such a document indicates that all parties have agreed to work to achieve, or work within the constraints of what the document describes.
In an agile world, it is essential to ensure that all parties follow the principle of documents, including contracts, being created only where they add value. They should be ‘light touch’ and ‘guiding’ wherever possible. Locking down the details of solutions too early is counterproductive and inefficient, as every change to the detail should really be agreed upon and signed off by all those who signed the original document. Often, people with authority to sign such documents and authorise changes to them are signatories who are rarely interested in such detail and, at times, are not close enough to day-to-day work to deal effectively with the real intricacies.
To optimise the value of any necessary contractual documents, they should be co-created, with the focus on what is needed to make the project successful, rather than on how blame for failure should be apportioned. If agility is expected, then effort should be invested in ensuring that people with the proper knowledge and technical and interpersonal skills are engaged in the project, committed and energised to deliver, and empowered to make informed decisions promptly. Strength in these areas will significantly support collaborative working.
Responding to Change over Following a Plan
This value acknowledges that the world around a project, or any other form of endeavour, is rarely frozen in time. We live in an increasingly VUCA world where the pace of change tends to invalidate the details of plans just as rapidly.
Any approach that does not accommodate, or ideally embrace, change is unlikely to lead to a successful outcome. Since significant change in short time frames is a fact of life in the modern world, creating detailed, long-term plans becomes a waste of time.
In a fast-moving business world, high-level, ‘light touch’ and ‘guiding’ plans, focused on short to medium-term goals, are best. That said, longer-term planning horizons are valuable for providing vision, direction, and focus, particularly for a context broader than pure product development. However, restrictive solution-oriented detail in such plans must be avoided.
The Manifesto’s Final Sentence
The final sentence in the Manifesto states: ‘That is, while there is value to the items on the right, we value the items on the left more.’
It is important not to shun processes, tools, documentation, contracts, and plans but to ensure, instead, that they are only created where they add value and only to the level of detail that adds that value. For this reason, it is important to be wary of using standard tools and templates intended to provide an organisation-specific governance framework.
Instead, where possible, try to achieve the most effective balance of agility (emphasised by the items on the left) and formality (emphasised by the items on the right). Take the time needed to co-create simple, light, valuable alternatives to standard artefacts and be prepared to explain how these represent a more effective demonstration of control for an agile endeavour than the standard alternative.
Read about our Framework for Business Agility here
Get recognised as a Business Agility Professional here
Please note blogs reflect the opinions of their authors and do not necessarily reflect the recommendations or guidance of the Agile Business Consortium.