31–40 of 77 posts
I don't understand why Risk Management isn't a thing anymore. Reducing risk at cost of reducing quality of a product is not generating a "great product". It's great for reducing risk for investment. So, the "secret" lies beneath the actual product - quicker return of investment. That's what agile actually means now. Great.
Agile, MVP, Iterative development: these are common knowledge by now. But I think there are problem spaces where this does not really work becasue even an MVP must be huge, otherwise users will simply ignore the product. You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc... I think markets in problem spaces where you can start with a very small MVP…
And getting stakeholders, or users, in the loop and validating at each iteration is still worthwhile to make sure you actually build the right thing.
Agile, MVP, Iterative development: these are common knowledge by now. But I think there are problem spaces where this does not really work becasue even an MVP must be huge, otherwise users will simply ignore the product. You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc... I think markets in problem spaces where you can start with a very small MVP…
What I think the author should have used is a car. First, we design and test the suspension, then the wheels, then the brakes, etc until we have a working car from the ground up. Then we sell a lot of them.
The OS / game engine /car example is frightening because you have no intermediate value until the whole thing comes together. hiccups propegate.
However, an iterative approach would create a minumum feature version first.
A car with no suspension, 25 HP, and one seat. An OS with virtually no drivers, targetting single arch, bad scheduler, single filesystem, and single user.
These are, in aerospace analogies, testbeds in which you validate your long term vision while producing real things that can be sold, hyped, or used to look for improvements and bad assumptioms before the final product is produced.
I completely agree with your statement that markets become saturated with Min Viable Products ... but that is what forces iteration. I agree with the author (and this isn't new knowledge) that iteratively buidling a better thing by expanding a pre existing thing helps you capture and scale.
My opinion is this probably gets hard once that thing gets big, and starts to feel clunky, and thats where the big companaies do a "re-engineering" with a waterfall-like model. They can afford to take time to design soup-to-nuts because they are still selling the iterative MVP mutant that got them to dominance. Different strokes for different folks.
I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig…
> Iterative development: the secret to great product launches I'd argue that often far from being helpful. Some of the best tech bosses I worked under would've shove a person out of the window simply for uttering a word "iteration." One told about that approach as - "trying to construct an airplane by making changes utill it stops crashing on takeoff" It a good to have a distinction in between software being iterated…
https://www.cs.umd.edu/~basili/publications/journals/J90.pdf
I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig…
I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig…
Earlier quoted context omitted.
This is the conventional wisdom, but in my n=1 experience, I have never seen the “ideal case sequential development” actually work in the wild. The ideal case presumes that everything is known when the sequential development is planned, which is what permits it to be optimized. But in my n=1 experience, everything is not known, the development team is constantly discovering new information, requirements change, and t…
“Scrumfall” - Sounds fun /s >> So I am left extremely cynical about the “ideal sequential development” Off course, in development/engineering work that has unknowns. But taking TFA example of building houses, most / all developers would do the foundations of all the houses first before moving on i.e. working sequentially.
2 important reasons are: 1) the project is around 6 years in total 2) the company has to fix any issues with the house for the first 2 years.
If they did all the foundations first, they’d have exactly the problem described in the article - no money till right at the end. Instead, they get money the entire way along and use that to finance the rest of the project. This isn’t an optimisation, iterative delivery is essential to their viability as a business.
They also eat the support costs on houses they build. That means they are repeatedly changing “features” in the houses to minimise those support costs. Just walking down 1 street you can see the evolution of the houses over time as they fixed various small issues with the original design. The houses look basically the same to a casual observer, but are quite stark to someone who lives in one of the versions. They are very obviously agile, and have a great system for inspecting and adapting. That doesnt happen on 2 week cycles, but it does happen at a pace appropriate for them.
Agile, MVP, Iterative development: these are common knowledge by now. But I think there are problem spaces where this does not really work becasue even an MVP must be huge, otherwise users will simply ignore the product. You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc... I think markets in problem spaces where you can start with a very small MVP…
right. the house example is plain wrong. What I think the author should have used is a car. First, we design and test the suspension, then the wheels, then the brakes, etc until we have a working car from the ground up. Then we sell a lot of them. The OS / game engine /car example is frightening because you have no intermediate value until the whole thing comes together. hiccups propegate. However, an iterative appro…
I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig…