Yes, obviously over-analysis/over-engineering is also bad but I'm not sure why that provides any evidence that doing none is good.
It is definitely not impossible to fail fast and emphasize MVPs and shipping while still being highly organized. People do it all the time, and they produce way more useful features than the GSD'ers because they are organized. And by the time they've been working for a few months they are moving faster than the GSD'ers (in my experience anyway, the actual timespan probably depends on how complex the problem is).
Maybe we aren't agreeing on what exactly GSD is? Because even on tiny projects where you come up with an idea and ship an MVP a week later I've abandoned the GSD style blind flailing. I spend maybe 5% of that week thinking about it and planning a few things out, altering that plan as you build it and another maybe 10% keeping technical debt low. That thinking time saves at least a few dead ends that I would have otherwise gone down. The low tech debt makes debugging easier throughout the entire rest of the 85%.
That 15% investment has never not seemed to pay off. Not so far. And then on week two, when there's feedback and it's time to iterate you are sitting pretty, not starting from scratch and just winging it some more like you would be with the GSD strategy. I've done both, and I really can't emphasize enough how much of a payoff there is to keeping lightweight, flexible but mandatory process in place. Always.
GSD style cowboy development is something I kick myself for wasting so much time with when I was younger, and it is totally natural to fall into that style when you like writing coding and are lazy.
Sorry, that was quite the wall of text, I guess that's my 4c.
It is definitely not impossible to fail fast and emphasize MVPs and shipping while still being highly organized. People do it all the time, and they produce way more useful features than the GSD'ers because they are organized. And by the time they've been working for a few months they are moving faster than the GSD'ers (in my experience anyway, the actual timespan probably depends on how complex the problem is).
Maybe we aren't agreeing on what exactly GSD is? Because even on tiny projects where you come up with an idea and ship an MVP a week later I've abandoned the GSD style blind flailing. I spend maybe 5% of that week thinking about it and planning a few things out, altering that plan as you build it and another maybe 10% keeping technical debt low. That thinking time saves at least a few dead ends that I would have otherwise gone down. The low tech debt makes debugging easier throughout the entire rest of the 85%.
That 15% investment has never not seemed to pay off. Not so far. And then on week two, when there's feedback and it's time to iterate you are sitting pretty, not starting from scratch and just winging it some more like you would be with the GSD strategy. I've done both, and I really can't emphasize enough how much of a payoff there is to keeping lightweight, flexible but mandatory process in place. Always.
GSD style cowboy development is something I kick myself for wasting so much time with when I was younger, and it is totally natural to fall into that style when you like writing coding and are lazy.
Sorry, that was quite the wall of text, I guess that's my 4c.