3 ms·

How would you build a rocket if you only thought about the next 2-4 weeks? Okay, I’ll bite... I’ll grant you the 2-4 weeks part isn’t quite right for building

How would you build a rocket if you only thought about the next 2-4 weeks? Okay, I’ll bite... I’ll grant you the 2-4 weeks part isn’t quite right for building a rocket; but the key insight of Agile, of developing in small steps and staying flexible, definitely applies. You do not start by designing the entire rocket before building anything. Your rocket won’t work. You start, you must start, by building a series of prototypes and exploring the design space. As you do that, you gradually refine your ideas of what’s possible and how to do it. As far as I know, every successful rocket design has followed that path. Sure, at some point along the path, you put together the blueprints for the final design. So there’s an element of waterfall in there. But staying agile is still critical. Unexpected stuff is sure to come up and you have to retain the flexibility to deal with it. As others have noted, software is somewhat special in that it’s cheaper and faster to build than physical stuff, can be copied and refactored much more easily, etc. And that shifts the agile-to-waterfall balance where you can realistically talk about working entirely from short term requirements.

rubidium 6y ago
Yes and that’s what almost everyone does. Learning loops with prototypes til you have a feasible product. But then you need a big development plan for how to scale it to a polished, sellable product. Because there’s a lot more to the product then the artifact.
- lmm 6y ago
  > But then you need a big development plan for how to scale it to a polished, sellable product. Because there’s a lot more to the product then the artifact. That's a total non sequitur. Agile is all about building the sellable product. But doing it iteratively works a lot better than doing it via a big development plan.
  - rubidium 6y ago
    You’re getting downvoted because you may have missed my point. To clarify for your sake, once you have hardware in the loop (eg mechanical engineers designing things, manufacturing scaling for production) and a large commercial organization who needs to be ready for a product launch, you need a waterfall type plan. Agile principles (customer focus, respond to change) can apply, and you can break up the work into 2 weeks, but you do need to look past the next 2-4 weeks and know where things are planned. Commitments matter in the $millions. Software-only SAAS has the luxury of avoiding that complexity.

rubidium 6y ago

Yes and that’s what almost everyone does. Learning loops with prototypes til you have a feasible product. But then you need a big development plan for how to scale it to a polished, sellable product. Because there’s a lot more to the product then the artifact.

lmm 6y ago
> But then you need a big development plan for how to scale it to a polished, sellable product. Because there’s a lot more to the product then the artifact. That's a total non sequitur. Agile is all about building the sellable product. But doing it iteratively works a lot better than doing it via a big development plan.
- rubidium 6y ago
  You’re getting downvoted because you may have missed my point. To clarify for your sake, once you have hardware in the loop (eg mechanical engineers designing things, manufacturing scaling for production) and a large commercial organization who needs to be ready for a product launch, you need a waterfall type plan. Agile principles (customer focus, respond to change) can apply, and you can break up the work into 2 weeks, but you do need to look past the next 2-4 weeks and know where things are planned. Commitments matter in the $millions. Software-only SAAS has the luxury of avoiding that complexity.