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 …
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.
Was this article helpful?
Also in Blog
Source controlling database code and automating deployments is a tricky business. To work quickly and maintain control over changes, developers need both productivity tooling to help generate code qui...
Also in DevOps
We sometimes receive questions from customers who are moving to use Microsoft's Azure SQL Managed Instances as to how Redgate can help manage backups.
This is a tricky question because Microsoft's ...
Also about agile
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.