How 17 men in a cabin came up with Agile 👀

Remind of ORG.OS 

I want to highlight that these posts are not an attempt to sling mud, instead, I see them more as an opportunity to use them to create a modern patterned language, which is an approach that doesn’t fit into a one-size-fits-all all cookie-cutter approach.I believe value comes when a team has a consistent language and a tailored approach to working that can adapt to specific wants and needs of the team and projects while not disrupting workflow. Now, before you say well that’s the idea of everyone following a set approach, I hear you, but the reality is very few organisations I’ve seen have ever managed to achieve this nirvana state. Those who try to force an approach in the team almost always fail here’s my take on the Agile Manifesto and agile as a term, why it can be a massive waste of time and how we can take some value from it

---

TL;DR

In 2001, 17 people crafted something called the Agile Manifesto,  introducing a revolutionary approach to software development that emphasises customer satisfaction, adaptability, and team collaboration over rigid processes. This manifesto has 12 principles, 4 values, advocates for continuous delivery, embracing change, and prioritizing working software. 

It aims to inspire modern organisations to adopt flexible, effective strategies that focus on innovation and efficiency. The creation of the Agile Manifesto marked a shift towards prioritising customer needs and streamlined teamwork, principles that guide effective organisational practices today. I believe agile should be seen as more a value or agreement then a set way of doing things, because every organisation i've seen try to do it fails in a process purest way fails

How it started

Back in 2001, the Wasatch Mountains in the background, 17 men got together in a cabin woods some where to write a 'manifesto'. Now, if we look past the fact they were all men and if we play blind to the fact there were 17 of them together over a weekend in the mountains all possibly naked* what we got from them spending this valuable time together was something called the agile manifesto (AM)

So first lets have a look who these 17 people aka the Snowbird 17 were:

• Mike Beedle

• Arie van Bennekum

• Alistair Cockburn

• Ward Cunningham

• James Grenning

• Jim Highsmith

• Andrew Hunt

• Ron Jeffries

• Jon Kern

• Brian Marick

• Steve Mellor

• Ken Schwaber

• Dave Thomas

• Kent Beck

• Martin Fowler

• Jeff Sutherland (Wrote Scrum, which comes in a later article)

• Robert C. Martin

Why did they create this?

Honestly, they were just plain old fed up of organisations taking forever in the admin, planning, and documenting of the software devs, and spending less and less time pleasing the customer, to the point where pleasing the customer became a bit of a distant memory with a deep desire to change this, and the fear of going home to their other half's empty handed with nothing to show for the weekend spent together. The group created a list of 12 principles and some pairing values

These 12 principles are:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software 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.

• 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.

• Working software 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.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity--the art of maximizing the amount of work not done is essential.

• The best architectures, requirements, and designs emerge from self-organising teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

The pairing values:

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

The reason they pair the values isn’t to disprove one half, it’s more to be clear that when push comes to shove one trumps the other

Example: Individuals and interactions trumps processes and tools

(Process and tools are still important, but they shouldn't block individuals and interactions

---

AGILE VS AGILE Veneer

When I think about being agile I like to think of it like a good DJ.

Professional DJs have planned the tracks out in advance, they know the tracks they want to play and the value it will give to the crowd. These DJs understand what makes a good track is how the various instruments, vocals, sounds and synths build on each other, and how the track perfectly sets up the next track to create a great piece of work.

A good DJ can read the crowd and know when they need to add some or take something away to make the experience more valuable to the customer i.e. the crowd, it’s here when they need to slip into their toolbox of other tracks should they need to change things up, like add in a big dirty bass line or increase the tempo.

In my time I have worked with many clients who state they’re being agile (or a world-class DJ in this case), however often when you look under the hood you see there’s not actually a DJ, instead, they are using AI and an auto mix button to put the tracks together. They lack the understanding and importance of knowing when to add in other tracks. Instead, they have one track list with no awareness of how each track complements the other, in the end, the outcome is each track operates as its own song and not part of a bigger set

To the untrained eye and ear they may look like they are mixing tracks but what they are really doing is winging it, in the chaotic mess of mismatched beats and non-complementary tempos the gaping hole of adapting to the audience is missing.

Many think being agile is about being completely flexible and it’s not, agile as a value is more about being structured in ways that play nice with other tracks, it’s about having awareness of knowing when and how to slip into the record box and put on another track without jarring the mix

What can we take from it

To me, Agile is more a principle, value or some best practices for teams and cultures (however that's not always good)

Later in this series when we get to writing a manifesto don't be surprised when you see elements of this agile come through. Will it be called out as being agile? Probably not. Will it be threaded throughout? Most certainly yes. Without having the agility and responsiveness in how we think, work flows and how we adapt to adding customer value then everything else tends to fall over. Another good but often overlooked thing we can take away from this is lucky it was before the age of the LinkedIn influencer, which meant that creating this manifesto was built on good intentions, there was no clout chasing. Getting 17 experts who all approached agile in the software sense very differently to remove their own ego and agree on something is worth shouting about

*walked naked in a cabin was added for dramatic effect, I am sure they were all fully clothed... probably. The image of men is also used for effect