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 bring it up in a retro where you should discuss if processes, including scrum events, are helpful and, if not, how they can be improved to actually be helpful. maybe the sprint is really too short. or there are too many items in it. or scoping/estimation could be improved. ideally teams should discuss this regularly
@kwramm I'm not talking about a specific project. I've been in a few dozen projects, and two-week sprints have never done any of them any good. They just stress people out.
@jzillw oh, same here. but I also experienced scrum where we made it work. Although it wasn't your typical waterfall game-dev scrum with 30+ people teams (that's scrum in name only). key is that you have leaders who can make scrum work for you. sprints can and should be longer if it helps the team
@jzillw If one is doing SCRUM "right" (not an easy thing) then this shouldn't be the thing
You either increase the sprint time if the tasks REALLY take that long OR if things are half done, they haven't been sized correctly during planning
Management tends to treat this as having something to hold against the team every two weeks but the idea is (supposedly) that the reason for the sprint is "protection against clients clienting"
Because every sprint turn is an opportunity to pivot [+1]
@jzillw The team commits to a certain set of "stories" which are all individual bits of functionality that CAN be implemented within the sprint (however long that is)
And then if suddenly you need to do something entirely different that doesn't come into like "okay, so client wants this tomorrow, lol". The idea is these things get filtered through the whole process and become stories for the next sprints....
So yeah, it's a thing with a specific purpose, for solo projects, it makes less sense
@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. 