[freshhawk]

In my experience GSD is just an excuse to avoid the organization and planning work that's not particularly interesting compared to banging out some code.

I've seen a lot of startups just failing utterly because their primary philosophy is this one, and it tells them that it's ok to skip the hard/boring parts of your duties.

On the plus side those who are thinking through their experiments and still failing fast but intelligently choosing what they are trying rather than just skipping the planning and hammering out some code can really out-compete their GSD'ing competition. I have some good friends doing exactly this and doing it very consciously right now (just yesterday I told them they should call it Hammock Driven Biz Dez since we are all Rich Hickey fans). It is working very well, and that's measured in revenue.

[perlpimp]

Last company I worked at, we were doing planning for 2 years and have yet to ship a product. There is something to be said for GSD, but only for startups in teams of under 10. Why? - because shipping a product gives you something to look forward to, live product is something you can brag about show and change the world with. It is better to ship than not to ship. If you can't do it in 2 months - cut features out, etc etc.

If you have razor sharp focus and most people are apt in their roles and know what to do without looking up to a central person - thats called teamwork. However when you get to point when you start getting less focused and start looking for a new target, things got to get reorganized, thats when GSD is useless. When realigning troops you got to give some wiggle room instead of blindingly forging ahead, maybe off the cliff. When you hire more people - grow beyond original team - GSD can be a bit hard to deal with and frankly destructive on the whole to the growth of a company.

It is never easy.

my 2c.

[freshhawk]

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.

[jakejake]

I'm not sure why so many teams go for the extremes - either zero planning, or planning out the wazoo! For most situations the best methodology is going to be somewhere more near the center.