I spent the first 15 years of my career as a toy builder, or “Software Engineer” as the recruiters preferred to label me.
I probably wasn’t the greatest toy builder in the world, but the toys that I built always had both function and form — I only wanted to build toys that the user would adore.
As my toy building career advanced I found myself working on more and more complex backend systems, with no obvious end-user, that would often take years to complete.
This ultimately led to my first (paper round excluded) career pivot; when I hung up my toy making tools to become a full-time Agile practitioner.
I had always been aware of the Agile manifesto of course (I would reference it occasionally during Scrum Master and Product Owner stints), but it would be misleading to suggest that I knew it off by heart.
If I wanted to be a credible Agile Coach I concluded that this would no longer cut it, I needed this information on the tip of my tongue so I could refer to it on demand, and without error.
At 1423 characters, that form 204 words and 16 statements, the Agile Manifesto is no lean document (sorry). It lacks structure and the 12 principles, in particular, are challenging to remember. This can lead to teams cherry-picking the principles they can recall and ignoring the ones they can’t.
As I set about attempting to commit the Agile manifesto to memory I started to discover a certain pattern that made it much more digestible. Not only could each of the 12 principles be mapped to one of the 4 values, but I also noticed there was an eloquent symmetry to it that often makes me wonder if it wasn’t by design.
At 1423 characters, that form 204 words and 16 statements the Agile Manifesto is no lean document.
Step 1 — Segmentation of the Manifesto
The first step to Mind Mapping the manifesto was to somehow segment it. I needed to find a way to break the manifesto up into smaller groups of related values and principles and to do that I needed logical memorable categories.
Given the Agile manifesto contains 4 value statements this seemed like the logical place to start, so I converted each value statement into the following 4 succinct categories:
- Customer — Customer collaboration over contract negotiation
- Quality — Working software over comprehensive documentation
- Team Agility — Responding to change over following a plan
- Collaboration — Individuals and interactions over processes and tools
Step 2 — Mapping the 12 Principles
In order to simplify this step, I highlighted what I considered to be the key message of each principle and focused on the less contentious mappings first.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Customer — customer value, a nice easy one to kick things off.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Team Agility —welcoming change, the ultimate test of a team's agility.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Customer — frequently deliver working software, let's hear it for the customer.
4. Business people and developers must work together daily throughout the project.
Collaboration — working together, the very definition of collaboration.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Team Agility — trust and motivation, essential ingredients of any high performing Agile team.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Collaboration — face-to-face conversation, remains the most effective form of collaboration.
7. Working software is the primary measure of progress.
Quality — working software as the primary measure, can only mean one thing.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Quality — sustainable pace, the quickest way to reduce the quality of any product is to work at an unsustainable pace.
9. Continuous attention to technical excellence and good design enhances agility.
Quality — technical excellence and good design, a slightly contentious one to categorise given the word “agility” as it could be argued that this belongs under Team Agility. However, given each principle enhances agility the focus here is clearly technical excellence and design which can only mean quality.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
Customer — maximising work not done, with many Agile teams becoming ‘feature factories’ and delivering solutions that are never used it essential to ensure the customer has a seat at the table.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Team Agility — self-organising teams, another essential ingredient of any high performing Agile team.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Collaboration — becoming more effective, another tricky principle to categorise as it could fall under Team Agility. However, I feel it is difficult to imagine how a team can implement continuous improvement without collaboration so that gets my nod.
To my surprise not only did all the principles (and values) map to my 4 new categories, but they did so in equal numbers!
The industry has seen a shift in focus away from Agile frameworks to the core Agile values and principles in recent years which has increased the importance of mastering the manifesto.
Hopefully, this mind map will help Agile practitioners and teams memorise the Agile Manifesto and ensure they implement more, if not all, of the Agile principles and values.
As I will hopefully show in subsequent articles, the consequences of not fully implementing the Agile manifesto can have a significant impact on business agility.