This is my blog. There are many like it but this one is mine.

Post navigation

Rockets before Rovers: The Agile Moon Landing Project

When a pack of Software Engineers met in Utah in early 2001 to discuss a new way of building software, the summit did not produce a brand new SDLC, but rather a simple set of guidelines for software teams to follow in order to achieve better results with less friction. This ‘Agile Manifesto’ was as much a guiding force for future software development as it was an indictment of the processes that continue to plague the industry. As simple as the guidelines are, they can be profound when applied properly:

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.

I find it informative to invert the guidelines and ask ourselves what it looks like to build software badly. If you want to build it the wrong way, you’ll define the process and choose tools first, write a whole bunch of documentation and requirements before you write any code, negotiate a detailed client contract but ignore those clients while you’re writing the code, and stick firmly to your plan regardless of what happens along the way. As horrible as that sounds, I’m afraid it also sounds pretty familiar to anyone who’s been in the industry for a while.

As simple and straightforward as those guidelines are… and I do believe they should be at the heart of any software development exercise… they do not prescribe any particular SDLC to achieve those results. In fact, that would be quite contrary to the first guideline!

In practice, however, all ‘agile’ projects are run as some form of iterative, or incremental, process. And that process is not a new one. Many people believe that ‘Agile’ is some new, cutting-edge software process and that moving to this new process is somehow revolutionary and, perhaps, risky. As a result, I think there’s a lot of resistance to those changes.

In truth these iterative approaches have been around for quite a long time, going back as far back as William Deming in the 1940’s pushing his Plan-Do-Check-Act cycles for improving the automotive industry. NASA’s Project Mercury, the opening project in the ‘space race’, as well as Project Gemini and the moon landing all followed incremental development cycles. Project Mercury did half-day iterations with test first development! Not such a new idea after all, just an industry that’s been very slow to catch on.

So, what does it really mean to do iterative development? Well, very simply, it means that NASA didn’t get hung up on designing an anti-gravity pen to allow astronauts to write in space before they even had a rocket to get them there! They knew, first things first, they better figure out how to make a reliable rocket capable of putting something in orbit, first… and that’s where they started.

And that’s the absolute heart of agile development. You don’t need a big fancy process with multiple steps, regular meetings, status updates, burndown charts, etc… if you do a little bit of planning, build your features incrementally, talk to each other and your clients, and make changes whenever necessary… then Congratulations, you’re doing agile software development! I see far too many groups getting all hung up on doing all the little details of Scrum process, or Extreme Programming or Kanban… all of those things are great but you don’t need to start with all that.

Go ahead and read about Scrum and Kanban… it will be helpful eventually, but you really need to start simple. The big secret is that you should design your agile process using agile methodology! Start with the core (iterations and demos), and end each iteration with a retrospective meeting to see what’s working and what’s not and fix it. Be patient, and your process will improve week over week. Plan your projects carefully from the core outwards and always remember: Rockets before Rovers!

Related Links:

A brilliant look at the history of incremental development, including some interviews with Project Mercury engineers:

3 thoughts on “Rockets before Rovers: The Agile Moon Landing Project”

I have to say (and that’s my personal opinion) is that Utah meeting happened for the sole reason to gain consulting contracts. Agile, Scrum, XP, whatever you want to call it, is just a set of best practices that existed way before the meeting, but that meeting transformed the whole thing into a cult, and marketed it as the best thing since sliced bread. Companies are now adopting Agile en masse, thinking that their PM will be better and believing this. It is not. We have an article on PM Hut comparing the success rate between Traditional and Agile, and the article concludes that Traditional’s success rate is higher.

In any case, Agile is the trend right now and there’s nothing that we can do to change it. The people who are really laughing are those who were in that Utah meeting.

That’s an awfully cynical view to take. No one should be adopting agile to have ‘better PM’. You adopt agile to have better products, deliver value to clients earlier in the development pipeline and, most importantly, to discover flaws as early as you can in the process.

Although, of course, many of the ideas originated prior to that meeting, that does not mean there was not value in looking at all the different approaches at the time and examining what was common across the more ‘successful’ projects (however subjective).

I’d agree there’s a lot of capitalization on the agile trend in the consulting world, but that should not be used to indict agile culture in general.

You do not say you had a ‘study’ but rather an ‘article’ comparing the two and concluding things… that sounds awfully subjective. Even if a real study was conducted, no two agile processes are alike… there are many claiming to be ‘agile’ when they really just have a facade over a waterfall, PM-driven, GANTT chart approach.