# Wednesday, 16 January 2013

How did we get to the moon - Part 2

Here's a daft question, which mission first landed humans on the moon? Apollo 11 of course, but lets think about that. It wasn't Apollo 1, it was Apollo 11. What on earth were the other 10 missions costing millions of dollars for then? 

Apollo 11 footprint

Well, I've had a good think about it, and this is another aspect of I find admirable about NASA's approach. As I mentioned in my last post, they had a backlog, and took achievable chunks from it, and finished them before moving on to the next. 

Mercury was all about getting manned spaceflight, Gemini was what NASA called "a bridge to the moon" - to work out how Apollo could be achieved, and Apollo was about getting to the moon. 

So lets start at Gemini. The mission goals were 

  • To subject man and equipment to space flight up to two weeks in duration.
  • To rendezvous and dock with orbiting vehicles and to maneuver the docked combination by using the target vehicle's propulsion system;
  • To perfect methods of entering the atmosphere and landing at a preselected point on land.

(source NASA)

All of these were the perceived steps needed to prove that a mission to the moon was possible. In a very agile way in 1964, NASA worked out that the original goal to land on land was not needed after all, so the mission was brought to a close early. 

So what did they get from Gemini? They got:

Validated Learning

They got the Validated Learning by delivering real missions. How often have you come across IT projects that are in a 'proof of concept' phase that deliver no real working value. The team gets to have a whale of a time playing with code that "we don't need to QA because it will never go into production" with the aim of getting learning of how to do real work. Only to find out a month later when the real work starts that most of what they learned was invalid, and that reference architecture we built was a bit Mickey Mouse. 

Proof Of Concept still means going live

Freeflyer nasa

Not NASA, they built real rockets, with real spacecraft on top, put real people into them and conducted real work that went into production. I can't imagine the rocket scientists saying, "we didn't bother testing the space suit systems properly, because this isn't a production mission to the moon, it's just a proof of concept." The astronauts were going out into the vacuum of space, so everything had to work with quality. 

Gemini had 10 manned space missions in about 18 months. They turned around their iterations quickly in manageable chunks, with the first 4 missions going from 4 hours to 4 days, to 8 days, to 14 days. Goal 1 achieved, two week manned spaceflight, move on to goal 2, docking. Interestingly part of the 14 day mission was a subgoal attempting to dock craft which failed. A lesson in limiting WIP for NASA right there ;-)

Keep the team together

The Gemini mission was piloted by names you will find very familiar - Armstrong, Aldrin, Collins, Lovell et al. Names you know from famous Apollo missions (11 and 13 in this case). In other words they had another Agile principe at heart. They built a great team, finished the mission, then kept the team together and brought the next mission to them.

How often do we put together a team for a project then disband it, and put together a new team for a new project? Good agile has teams staying together and work is brought to the high performance team as it completes other work. 

On to Apollo

Similarly with Apollo, each mission was designed to gain validated learning. 

As13 nasa

Apollo 1 was a disaster with a fire in the cabin killing all of the crew, which led to changes in the cabin design, and better escape systems. A harsh lesson that led to important learnings for the rest of space flight. As with most projects that go wrong, the lessons we learn tend to be the most important ones. 

Apollo 8 was the first mission around the moon - the furthest away man has ever travelled. 

Apollo 9 was the first time the Lunar Module was tested separately from the Command Module, launching, manoeuvring, and docking in space. 

Apollo 10 was everything up to but not including lunar landing. They launched the Lunar Module and went down to within 9 miles of the surface of the moon, then came back up, docked and came home. 

Apollo 11 was the biggie. Neil may have fluffed his line ( "one small step for a man," is how it was supposed to be) but mankind was on the moon for the first time. 

Apollo 12 onwards was about finding out how man could spend longer time on the moon, and potentially set up a base there in the future - hence the lunar rover etc. 

Each mission built on the learnings of the previous mission, adding another valuable increment of validated learning, until the final objective was achieved. 


This equates to a project releasing valuable increments and evolving through the validated learning gained until you have a Minimum Viable Product to launch to market. Gemini and Apollo 1 through 10 gave the increments and validated learning so that Apollo 11 could happen, and that progressed throughout the programme to the final mission to the moon (40 years ago). 

One Final Thought For Mankind

Can you imagine the Big Bang waterfall approach as applied to the Apollo programme? Imagine if Gemini 1 had to go and land man on the moon with no missions in-between. Do you think it would ever have even taken off? I suspect it would have been cancelled after 15 years of theoretical work, and been an abject failure. They just didn't know all of the things they needed to learn up front, it was only by launching the missions that they found out all of that Validated Learning that made the objective possible. You don't learn everything you need in a theoretical POC phase, you learn by doing things for real. NASA was doing this on the highest profile project in the world in the 1960s. Finishing one small step at a time. 


Tags: Agile | Kanban | Lean | LKU | NASA | WIP

Wednesday, 16 January 2013 11:22:06 (GMT Standard Time, UTC+00:00)  #