HD: Most of the stuff that we do nowadays, we take these short cycles, and that's the best way to go about it. Curiously, if you actually look back in history, even NASA, when they were developing the Apollo program, really had a very agile technique of going through and taking small steps and verifying as they were going that they were doing the right kind of product.
JV: That's interesting. Can you into a little bit more of that?
HD: Well, it comes from Craig Larman. He did a lot of this original research on it. Just think about the project in whole. You have a ten-year product, and eventually the goal was to put men on the moon. And along the way, there were lots of small steps. They would build a booster and have an unmanned launch of it and make sure the booster worked okay. Then they'd add a complexity on top of that, and they'd say, “Okay, let's put a booster on with the right kind of weight and check that the center of gravities all work.” Then they would put men inside of it. There was a Mercury part of the component, then a Gemini. Again, it was incremental development towards that final product.
And if you compare that with things like the Hubble Space Telescope, which was the classic big waterfall kind of project, they had a fairly minor defect where they forgot about the fact that gravity on the earth will curve the mirror differently than when it's in space and there's no gravity. This basically blinded the telescope. And I forget how many, it was like eight billion dollars to go fix that. Classic sort of like, “Well, we'll fix it at the end when we find there's a problem.”
JV: If only we could have found that earlier on in the stage.
HD: Absolutely. I mean, again, it would have been incremental sort of stuff. They would have launched stuff and then realized, "Oh my god, look at that. The mirror that we wanted to get up there is going to change a little bit in curvature. Hmm. Let's figure that out."
JV: Talking to these people who have been part of these organizations for so long with this old mindset, what are some of the challenges of trying to get someone to pivot to using an agile technique?
HD: Well, you know, it works best if you don't just say, "Here's a bunch of practices. Follow these things."
HD: Because the complexity of software that we write is huge. There's a lot of moving parts. The thing to do is to say, "What problems are we trying to solve, and how can we measure those things along the way?" So if the problem that we want to solve, for example, is faster delivery of product, then we can start to understand how to bring that testing forward, verify the stuff that we're doing iteratively, do it such that it costs very little to actually ship it and get feedback, complete that feedback loop, get feedback from our users and our customers that we're actually making the right thing, and then shorten that feedback loop about have we built the thing right—which is going to be all of the unit testing, the acceptance testing, the automated regression testing.