Recent searches
Search options
There are a lot of agile software practices that make a lot of sense, but I'm not a fan of the idea of a two-week "sprint".
I end up having a dozen features half-done, because each had to be ready by the end of the "sprint". I'd much rather spend three weeks each on eight of them, and have the other four dropped entirely (or handed over to someone else).
This isn't just a quality vs. quantity trade-off, because a well-done feature saves time spent on future related features.
@jzillw obsessively trying to do agile “by the book” is one of the banes of software-related companies and projects. The essence of agile is that no rule is set in stone and every part of the process should be scrutinized for its value. Anecdotally, I've been on a dozen of projects where switching from sprints to kanban at one point was one of the best decisions a team (and PM) could make.
@jzillw and re: half-baked features, this is also another issue with obsessing with the process – typically business expects that once a story is done then the feature is done and there should be no need to re-open it again. But this is often not true in case of projects with strong creative aspect (like games). The question is: should implemention of a feature be agile-driven if the feature requires iteration and tuning process.
@goshki I won't say "yes" or "no", but I'll give an example. In one project I worked in everything was fine until we introduced a tech tree. A tech tree is basically a bunch of things that say "this specific thing right here used to be a number but now it's a function". It turned out many of our features weren't ready for that. Would be nice to take the tech tree into account from day one, except no one could tell in advance what techs were going to be there, because it depends on playtests.
@jzillw great example showing how it's not possible (or sometimes just not feasible) to design/implement a feature upfront-ready for some future extension. That's why I'm a die-hard proponent of iterative approach (where iteration sometimes means implementing a feature gradually where each next step is informed be the previous one and sometimes it means introducing separate version of the feature and gradual exchange of its existing uses). YAGNI and KISS FTW! 
@goshki I advocate for KISS a lot and iterative approach has been my catchphrase for years, but also I've seen how commercial development can stand in the way of both. Simply put, iterative approach needs to be communicated in advance: we are going to revisit this feature, even though it looks good enough, and we are going to spend money on it again. But most investors would prefer to jump straight into pipelined production.
@jzillw yes, exactly! I think we've looped back to the initial notion of business people's aversion to spend time (and money) on something that was deemed done. 