|
|
|
|
|
|
by perlpimp
4605 days ago
|
|
|
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. |
|
|
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.