Exploring the values and principles which underpin Agile
After the birth of my daughter in 2014, our house was busting at the seams, so it was time to do a renovation to add a room.
Being the first time I had ever been so directly involved in a building project, it was quite daunting. Every day I would come home expecting that the builder would have discovered some unexpected issue or requirement and would hit me with curveballs or new costs.
But it never happened. Maybe I just got lucky. But when I quizzed the builder, he said it was a fairly straightforward job, the plans were adequate, and he had done countless renovation projects like this one before. So he knew exactly what to expect and how to prepare for it.

When I started out working in software development, I genuinely thought that the traditional approach to project management — which was intended for creating physical structures such as buildings — should apply perfectly. The linear nature of the process makes such logical sense, and it felt like just as long as everyone kept up their end of the bargain, it should be failsafe.
However, my first few exposures to commercial software projects quickly destroyed that illusion. Time and again, the plans never withstood contact with reality, and the way that changes to the plans were managed was cumbersome and ineffective. The result was stress levels steadily increasing for everyone involved, budget overruns, and outcomes that no one was really happy with.
It turns out that creating products for humans (software or otherwise) is a very different endeavour to building houses. Humans are complex, and it is hard to predict how they will respond to something new. It requires a different approach — one which embraces frequent feedback and the changes to the plan it inspires.
And this is the promise of Agile.
It offers a better way of getting the best outcome for the customer, and a better experience for the team.
Agile is an umbrella term used for several methodologies that embody a particular way of working. In 2001 a group of practitioners came together to identify and document the common values and principles that underpinned how they worked, and the result was the agile manifesto — 4 values and 12 principles, summed up in around 250 words.
Fast forward nearly 20 years, and as someone practising Agile, I can confidently say that the original manifesto has stood the test of time as a simple yet powerful embodiment of the core essence of this way of working. And that is why I still treat it as my starting point when thinking about how to best support a project or a team.
I would recommend reading the manifesto in its original form, on the website where it has always been housed since 2001:
Below I have added some thoughts to each of the points to help provide some more context for people new to Agile, and have attempted to speak in more general terms than being focussed on its application in a software development organisation.
The Four Values
One important thing to keep in mind while reading the four values is this statement which is in the manifesto itself — “… while there is value in the items on the right, we value the items on the left more”.
- Individuals and interactions over processes and tools
Great outcomes stem from groups of people focused on a common goal. Processes and tools help along the way but alone aren’t enough to make the magic happen. Giving people the time and space to interact with each other and form good social bonds pays dividends when it comes time to collaborate on the work at hand.
An example of this is related to the tools we use to manage our work. Digital task boards such as Trello and Jira are really useful for visualising tasks. However, it can be tempting for teams to fall into a routine where people individually update their tasks without actually engaging and interacting with each other. This value from the manifesto reminds us that while there is value in having a tool to help us track our work, it is more important to have conversations about what we are working on. We’ve seen this working very well for Haileybury through our use of Zoom.
2. Working software over comprehensive documentation
This is similar to the old adage that “a picture is worth a thousand words”. It is tempting to keep writing and defining an ideal end state. But in reality, any documentation written in advance of an outcome is full of assumptions and guesses. Once we put the thing we are creating into a real customer’s hands, only then does the actual value exchange happens and the learning begins.
This Forbes article excerpt illustrates how Spotify leveraged this principle to their competitive advantage:
“What enabled this miracle to happen is Agile. Spotify had created an organizational culture of Agile management in which autonomous cross-functional teams were encouraged to experiment and create new ways of adding value to customers. With Agile management, the team didn’t need to prepare a detailed cost-benefit proposal and seek a series of approvals up a steep management chain before they could try out their idea. They were used to working as a team, with radical transparency among the team members. They were already tightly focused on the user experience: they knew how to test alternatives and learn from the tests. Within a couple of weeks, the tiny cross-functional team had pulled together a quick prototype and tried it out on Spotify’s own staff — all active Spotify users.”
3. Customer collaboration over contract negotiation
A traditional project management approach means clearly defining a scope upfront, devising an approach and an estimate, and then negotiating a contract for how much it will cost to deliver the outcome. A lot of energy during the project is then put towards either sticking to that agreed plan or managing any variance from it.
In contrast, Agile approaches favour lighter weight processes that are built on a basis of trust, frequent communication, and a high degree of collaboration. Under these conditions, the team and the stakeholders can together decide what levers to pull when things don’t go to plan — e.g. is there a simpler and therefore cheaper way to get to the outcome? Or is additional time and budget required?
The real difference is how these conversations happen. Using traditional approaches there can be a much more rigid and adversarial feel when the parties feel like they are varying contract terms which were never meant to change. However, when the parties are acting as genuine collaborators, it is much easier to find alignment.
4. Responding to change over following a plan
When big plans are defined and documented in detail upfront, and when the corresponding budgets and timelines are agreed to, there are usually significant costs associated with making changes to that plan. By having lightweight plans and documentation, the cost of change is minimised.
This value is one of the key benefits of Agile — the ability to quickly and effortlessly respond to learnings from customers. The corollary to this though, is that if there isn’t an open mindset, and if learnings aren’t being sought out and responded to in a way which might influence the original plan, then there is little benefit in striving to be agile. If the plan is never likely to change, then it might just be more efficient to stick to a rigid plan.
The Twelve Principles
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Any team developing an outcome for customers (whether that’s software, a new product, or anything else) usually needs to make hundreds of micro-decisions along the way. Having the clear goal of delivering value to a customer quickly does wonders for providing clarity and focus on what is important, and that helps guide all of those decisions.
And by introducing the concept of continuous delivery of value, it opens up a whole world of working. There is no longer a need to get it right the first time: rather, just get the first version that can deliver some value, and then start learning and quickly follow up with the next version of whatever you are creating.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The second sentence here is the really important essence of Agile.
Change can be the difference between hitting the mark and achieving your goal or missing it. The saddest outcome would be to miss the mark, even though the need to change tack was identified, but either no one raised the concern, or if they did then it was deemed too hard to divert from the pre-existing plan.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This speaks to the idea of establishing a consistent ‘flow of value’ through to the customer, where it has a chance of generating revenue and/or learnings.
Having all of the team’s good, hard work sitting there dormant for an extended period waiting to be released to customers is genuinely wasteful.
For example, teams often have to decide when to deliver the first version of their product (whether that be software or a course) to customers. It can be a very uncomfortable feeling to have people use a version that isn’t as refined as you would ideally like it to be. However, as Reid Hoffman (the founder of LinkedIn) once said: “If you’re not embarrassed by the first version of your product, you’ve launched too late”.
4. Business people and developers must work together daily throughout the project.
Each additional layer of hierarchy involved in a project, whether that be a manager or an analyst of some kind, introduces delays and room for confusion. More importantly, though, all of the very important yet subtle signals which are communicated through body language etc are lost when there is a messenger in between.
The best outcomes are achieved when the people who desire the outcome (i.e. the people paying for it) and the people doing the work (i.e the team), are in frequent and direct contact, genuinely collaborating on the work in a trusting and transparent way. That doesn’t mean that they need to work together all day, but there does ideally need to be at least a daily touchpoint.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
A group of people working towards a common goal, with the space, tools and trust they need, creates a lot of energy and motivation. Small teams that between them have all of the skills they need to achieve their common goal carry a great sense of autonomy and ownership as the share and reorganise the work amongst themselves.
Too often, however, we see organisations optimising for perceived efficiency and cost-cutting — either treating people as interchangeable resources. This can be observed when certain parts of a business are outsourced to other companies, with the expectation that work can easily be handed back and forth between internal and external teams.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
A few people speaking face to face can achieve in 10–15 minutes a level of shared understanding that would otherwise take hundreds of written words and days or weeks of back and forth. Once there is agreement, then it can be quick to take the next step and commit it to documentation.
Distributed teams can take advantage of video conferencing technology such as Zoom to achieve this level of high bandwidth communication.
7. Working software is the primary measure of progress.
While planning and design are important, they don’t represent true value.
Value is only generated once there is something in the customer’s hands which they are willing to pay for. Achieving that outcome requires a lot of additional types of problem-solving at every level and step of the business, from how something is produced, how it gets in front of the customer, to how the customer pays for it. Only once that is done can actual progress be made.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
In many project scenarios, there is a big rush at the end as the deadline approaches. While this can be energising and exciting, it can also lead to people burning out, and making mistakes that they otherwise wouldn’t have.
By delivering valuable outcomes consistently and frequently, the team comes to understand what the realistic and sustainable pace is in their given environment, so there should rarely be a need to exceed that pace to meet expectations.
9. Continuous attention to technical excellence and good design enhances agility.
A helpful analogy here is the concept of a sink full of dirty dishes. If a team has continually taken shortcuts along the way, when it comes time to make a sudden change, then they may find that they need to do a lot of cleaning up first.
Conversely, if things have been designed and implemented in a deliberate and considered way — i.e. if the dishes were done along the way — then when the need to change tack arises, the team can respond quickly and without a fuss.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
This is one of the easiest things to say, and yet very hard to do.
It takes great discipline to keep things to their simple, core essence. It requires challenging every request that comes in the door and starting with a default position that it is not required until it is proven to be necessary. A related concept is YAGNI — “ya ain’t gonna need it” — as a reminder to be ruthless about minimising the number of bells and whistles that are incorporated.
One reason this is important is that every new feature that seemed like a good idea to add to a product also needs maintaining in some way. Once it is out there, it is much harder to take it away.
The better approach is to start simple, and then add only when customers tell you that they need something extra.
11. The best designs emerge from self-organizing teams.
The team closest to the problem being solved are best placed to know how to tackle it. To put that responsibility in the hands of designers or analysts who are not working directly together, and who are not close to the actual customer, will not result in the best possible approach.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
This is perhaps the single most critical aspect of agility.
By reflecting both on the progress that has been made, and the process which was undertaken to achieve it, a team can identify what is working well, and what isn’t. Creating a culture where people feel safe to be critical, but are at the same time supportive of each other, is essential for continuous improvement, and so a team can rapidly become self-aware and high performing.
I hope this summary provides some insight into the Agile manifesto and how the application of the values and principles might relate to your working environment.
In the Professional Development workshop and the through the Haileybury Microcredential in Agile Learning Design, we will take a deeper dive into the supporting tools and frameworks, as well as exploring case studies which highlight how agile has been applied in industry.