20 October 2017

2 Comments

20 October 2017

2 Comments

The real origins of the Agile Manifesto

In February 2001, 17 people met at the Snowbird ski resort in Utah. They were the leading exponents of Extreme Programming, Scrum, and Adaptive Software Development, and they were seeking a set of compatible values based on trust, respect and collaboration.

They wanted to make software development easier. And they found it in the form of a manifesto. Their only concern was that the term describing the manifesto came from a ‘Brit’ and they weren’t sure how to pronounce it.

The Agile Manifesto was, however, born …


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

While they saw value in the items on the right, they valued the items on the left more.

All of this is pretty impressive and it’s become part of the myth and folklore of Agile. It’s seen as the key to the door that opened up faster, leaner, better software development. It kind of made it sexy too. A bunch of mavericks holed up in Snowbird in Utah, plotting against the suits, the corporate slave-drivers, the nemeses of the galaxy … you get the picture.

But there’s a problem, a big problem. One about the size of the USA’s first ever jet fighter.

The skunk in the room

Step in Kelly Johnson. You’ve probably never heard of him but he was one of the most influential figures in 20th century aircraft design. In 1943, he was Chief Research Engineer at Lockheed and he was given the task of developing a jet fighter to counter the growing threat from Germany.

What’s this got to do with Agile? Everything. He put together a hand-picked team, they worked out of a circus tent because Lockheed was so busy building other aircraft for the American war effort, and in just 143 days the XP-80 Shooting Star was designed and built.

That circus tent was the beginning of what was to become known as the Skunk Works at Lockheed which, under Kelly Johnson, was to go on and develop further revolutionary aircraft like the U-2 spy plane and the SR-71 Blackbird.

It ain’t what you do, it’s the way that you do it

What’s important here isn’t the XP-80, or the U-2 spy plane, or even the founding of the Skunk Works. It’s the way Kelly Johnson worked. He had 14 rules of management which you can still read on the Lockheed Martin website.

Remove the ones about security, program funding, performance-related pay and military requirements, and four remain that refer directly to how work was organized:

  • The number of people having any connection with the project must be restricted. Use a small number of good people … compared to the so-called normal systems
  • A minimum number of reports, but important work must be recorded thoroughly.
  • Mutual trust between the military and the contractor with very close cooperation and liaison on a day-to-day basis.
  • A very simple drawing and drawing release system with great flexibility for making changes.

These are actually #3, #5, #12 and #4 of Kelly’s rules, but I’ve deliberately re-ordered them because a funny thing happens if you compare them with the Agile Manifesto:


Introduced in 1943

  • Use a small number of good people … compared to the so-called normal systems
  • A minimum number of reports, but important work recorded
  • Close cooperation and daily liaison
  • A very simple … system with great flexibility for making changes

Introduced in 2001

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

So before anyone in that historic meeting in Utah was even born, the Agile Manifesto they would create 58 years later was already, in effect, in existence. Which is a bit of a brain-flip.

Does it really matter?

Actually, yes. Rather than decrying the Agile Manifesto, it strengthens it. It demonstrates that the values behind Agile aren’t just the result of some pie-in-the-sky thinking from a bunch of people out of touch with business realities.

Instead, they’re based on principles which have already been tried and tested in industry. Principles that have resulted in hugely successful product development. Principles that may well be a natural response to bureaucracy, rigid systems and hierarchical management structures.

I found Kelly Johnson at Skunk Works, who fortunately wrote down his 14 rules of management. There are undoubtedly other examples – I’d love to hear about them if you know of them.

Importantly, if you’re introducing Agile or outlining its advantages to a skeptical audience, remind them that’s it’s been around for a lot longer than most people think.

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in Blog

Redgate data governance survey reveals database DevOps is the key to GDPR compliance

A major new data governance survey from Redgate demonstrates there are important GDPR compliance issues that need to be addressed – and that a DevOps approach to database development can provide the...

Also in DevOps

The four pillars of DevOps

Firstly, let's get something out of the way. DevOps is something that polarizes people because there are various definitions of what DevOps is. I actually never use the word with technical people beca...

Also about agile

Five ways we’ve implemented Agile marketing at Redgate

Implementing Agile working practices reminds me of Communism – if we just did it properly, everything would work perfectly! All projects would be a dream to work on, all deliveries would be early, t...

  • David V. Corbin

    Yes, the concepts and ideas [as well as practical application] far predate the Snowbird meeting in 2001. I was part of a [defense industry] team that leveraged them back in the 1970’s and 1980’s. The beauty and elegance of the Manifesto was that they were brought together into a single concise form, intended for consumption by others, for the very first time.

  • Jeff O

    If those in charge aren’t agile then nobody is, “marketing, or management, or external customers, internal customers, and, yes, even developers—don’t want to make hard trade-off decisions, so they impose irrational demands through the imposition of corporate power structures. This isn’t merely a software development problem, it runs throughout Dilbertesque organizations.” I think those involved with creating the manifesto were putting this into practice way before they managed for formalize it.