20 October 2017

5 Comments

20 October 2017

5 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 DevOps

Don’t just think database DevOps. Think compliant database DevOps.

The 2018 Accelerate State of DevOps Report from DORA specifically calls out database development as a key technical practice which can drive high performance in DevOps. It’s an interesting shift in ...

Also in Blog

Meet Redgate at PASS Summit v.20

PASS Summit turns 20 this year. We’re delighted to be in Seattle from November 6 – 9 as Gold sponsors of the largest conference for Microsoft Data Platform professionals.

Redgate will be presenti...

Also about agile

5 ways to increase productivity in cross-functional dev teams

With the craze over building Single Page Applications (SPAs), companies have joined the movement and hired armies of front-end engineers with/without experience in back-end technologies.

To accommoda...

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

  • –Jeff Moden

    Kelly’s rules make a whole lot more sense than the way the Agile Manifesto is worded. Kelly’s rules are worded better and seem less likely to be misinterpreted as the Agile Manifesto has, even though the authors of the manifesto were absolutely on the right track.

  • Could you also compare the Agile Manifesto’s contrasts to Charles Handy’s 1978 Gods of Management (http://community.jobscentral.com.sg/articles/handy-guide-gods-management)? In that light it looks like the Agile Manifesto is preferring Athena-style management culture to Apollo-style, but Handy’s models offer some interesting metaphors – how many projects have aimed for an Athena-style management culture but evolved into an unhelpful Dionysius-style?

  • Maja Könninger

    In my opinion the principles of the agile manifesto do really make sense. Maybe the way how they´re formulated can lead to msitakes and obstacles but the basic purposes of them can really help to improve your workflows. I´m working at Zenkit. We´re a young start-up from Germany which developed a project management tool. https://blog.zenkit.com/uncovering-the-agile-manifesto-af9435cc4f00
    A colleague of mine has recently publsihed an arcticle which sums up and explains the agile principles in a very comprehensive way. maybe its an useful addition to your article? Really interested in your feedback.