5 ms·

Setting aside the specifics of particular agile methodologies like scrum, etc I think the core insight of the Agile manifesto is that building software products

Setting aside the specifics of particular agile methodologies like scrum, etc I think the core insight of the Agile manifesto is that building software products is fundamentally different than building things like rockets. When you are building a rocket you more or less know exactly what you want to build from the beginning so doing a detailed up-front design is definitely the right way to go. When building a software product (or really most software products, there are of course pieces of software that are well specified in advance) you don't know what the end state is or even if there is an end state. The information flow is bi-directional in the sense that observing how the software is used in the wild feeds back into how the software should be designed.

gt565k 6y ago
Ughhh, you do realize that there are software systems out there probably just as complex as rockets, as they are, well, used in rockets themselves to control the physical parameters. You do know what the end-state is. It's called the minimum viable product, MVP. The most successful product owners are ones who are technical and can bridge the gap between the business requirements and technical implementation. For example, there would be no SpaceX and vertical landing of rockets if it wasn't for Elon Musk, who is both an engineer, a businessman, and an entrepreneur. He gets the full picture and can talk to all divisions of the company with incredible competency. If you have a product owner who knows nothing about building software, in charge of a software product, you'll have a much smaller chance of succeeding, than if you had someone who was both business and technically savvy.
- thinkharderdev 6y ago
  For what it's worth, I agree that the advice in the article is badly wrong. I'm just saying that building a rocket is fundamentally different than building a software product because a rocket is well-specified in advance. To you point, the MVP is different from the product as it will exist once fully realized. And the reason is because you don't know in advance how users will respond. You're not trying to satisfy the physics of rocket flight, but trying to please actual human beings who have weird and idiosyncratic preferences. So you build something (an MVP), let them use it and then incorporate their feedback into the next iteration. I'm with you in the sense that once you have a concrete MVP that you want to build, then you should approach building it as you would approach building a rocket. It's just that you may find that user didn't actually want a (proverbial) rocket, they wanted a helicopter.

gt565k 6y ago

Ughhh, you do realize that there are software systems out there probably just as complex as rockets, as they are, well, used in rockets themselves to control the physical parameters. You do know what the end-state is. It's called the minimum viable product, MVP. The most successful product owners are ones who are technical and can bridge the gap between the business requirements and technical implementation. For example, there would be no SpaceX and vertical landing of rockets if it wasn't for Elon Musk, who is both an engineer, a businessman, and an entrepreneur. He gets the full picture and can talk to all divisions of the company with incredible competency. If you have a product owner who knows nothing about building software, in charge of a software product, you'll have a much smaller chance of succeeding, than if you had someone who was both business and technically savvy.

thinkharderdev 6y ago
For what it's worth, I agree that the advice in the article is badly wrong. I'm just saying that building a rocket is fundamentally different than building a software product because a rocket is well-specified in advance. To you point, the MVP is different from the product as it will exist once fully realized. And the reason is because you don't know in advance how users will respond. You're not trying to satisfy the physics of rocket flight, but trying to please actual human beings who have weird and idiosyncratic preferences. So you build something (an MVP), let them use it and then incorporate their feedback into the next iteration. I'm with you in the sense that once you have a concrete MVP that you want to build, then you should approach building it as you would approach building a rocket. It's just that you may find that user didn't actually want a (proverbial) rocket, they wanted a helicopter.