20 Years of The Agile Manifesto

Can you believe the Agile Manifesto has been around 20 years?

What astounds me is that it’s in my lifetime: in my working career, actually.

Project management has changed a lot since I started working:

• We’ve got better collaboration tools
• We’ve adapted to remote working as the norm, not an exception
• There is greater awareness of the benefits of diverse teams
• More project teams include overseas colleagues and suppliers as the world gets smaller
• Companies can no longer mandate women to wear high heels at work (thank you, Equality Act 2010) – unless the same provision is also expected of male workers.

And yet…

The Agile Manifesto has probably had the greatest impact on how projects are done – even how non-agile projects are done. The concept of iterating, developing and focusing on value are principles that even predictive projects benefit from.

That meeting in the Aspen Room at The Lodge in Snowbird, Utah, certainly has a lot to answer for.

Celebrating 20 years

The Agile Manifesto date was 11-13 February 2001. That’s when the Snowbird summit happened and the 17 authors got together to work out how things for software developers could be better.

It has been 20 years since the Agile Manifesto, and that’s a moment worth marking. We’ve come a long way since the “birth” of a movement, and it’s hard to describe the impact that agile methods have had on the way work gets done.

It seems like every tool now includes an option to display work on Kanban boards, and that’s just the start of it.

I’m not an agilist (at all) but I use Kanban boards for my own task planning, and concepts like iterations, progressive elaboration and regular lessons learned meetings, which are small ways in which my own work has evolved and benefitted through an understanding of agile techniques.

What does the Agile Manifesto say?

The Agile Manifesto says:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

The Agile Manifesto Authors

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

The Manifesto gave this way of working a name, a community: something people could get behind. And people really did.

The 12 Principles behind the Agile Manifesto

The Manifesto is a short summary of what it means to hold certain values and work in agile ways. Behind the Manifesto sits a set of 12 principles which describe more about what it means to work in this way. They are not prescriptive, but they set the tone for what is important.

We follow these principles:

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-organizing teams.

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

Is the Agile Manifesto still relevant?

What dropped out of the meeting of the Snowbird 17 was an understanding of what was common between all the different ways of getting software development done. It was the bedrock of what it meant to be agile.

But on top of that, people were running projects in a range of different ways. And if anything, the agile landscape is more fragmented now than it was back in 2001.

We’ve got ways of scaling agile, and hybrid approaches, managers who say they are agile but do nothing an agilist would recognize. Agile broke out of software development teams a long time ago.

It seems like agile methodologies abound, perhaps because it is so tailorable to different environments. Agile teams take the best of the methods and adapt them, because that’s the smart thing to do for success at delivery.

However, the Manifesto still speaks to people. It’s a benchmark; a goal for what we can achieve if we use the right tools in the right situation. It’s more relevant now than ever, perhaps, because it provides the boundaries of what good looks like for getting work done – following principles of simplicity and reflection that scientists have used for thousands of years.

But is it relevant for non-software projects?

We can’t escape the fact that the Manifesto started life as an approach for the development of software.

From traditional software delivery to continuous software delivery, the key values underpin the processes that help get work done.

However, an agile process is also useful in a non-tech environment. Agile Marketing is a thing now. Many businesses have adopted agile principles, even if they wouldn’t consider themselves to be truly agile. Even totally ‘traditional’ companies can benefit from taking an agile approach to meetings.

I don’t see how you could deliver a large construction project while being agile, but I do understand the benefit of a daily standup for the core project team in that environment. There are benefits to adapting how we work to deliver the best outcomes for the customer and the team.

Just the fact that the Manifesto doesn’t talk about people as “resources” is something that many project leaders could learn from.

Project managers still have a place

The role of the project manager doesn’t really exist in many agile teams: instead, the team is self-organizing and supported by a Scrum Master (in Scrum), or agile coach. However, as the approach scales and goes more mainstream, the role of the PM is still needed. As I said to a colleague the other day, her business is not going to deliver a 2-year business transformation program in 2-week sprints. But some of the work within that program could well be suited to using sprints as the delivery method. Pick and choose… and that’s where hybrid comes in.

I definitely don’t believe that project managers are the dodo of the agile age. We still have a lot to contribute – and a lot to learn from colleagues using agile methodologies.

Here’s to the next 20 years: I can’t wait to see what evolutions are coming.