4 ms·
IMO sprints are a barely-adequate substitute for a coherent vision with priorities. In a chaotic (dysfunctional) business environment where things change on a w
by perrygeo 3y ago
IMO sprints are a barely-adequate substitute for a coherent vision with priorities. In a chaotic (dysfunctional) business environment where things change on a whim, sprints serve as a firewall to provide a few days/weeks of focus.
If everyone on the team is aligned and knows what the priorities are, sprints are rarely needed. When you do sprint, it's reserved for real emergencies. You don't need to play games to carve out time for X because everyone agrees that X needs to get done. Then when X is done, you move onto Y. Serialize. I won't say it's the only way to build software, but this method almost always produces a superior quality product compared to arbitrarily carving up tasks and trying to bin-pack them into sprints.
- bick_nyers 3y agoOne advantage of agile sprints that was pitched to me when the company I worked for was converting from 6 week cycles down to 2 week cycles was the power of this firewall and priority system. Customer Support giving you a hard time on this feature? Point them to the card and say it's in the next sprint. How I feel now about that firewall now? I'm looking for a company that has a competent technical dictatorship in command.
- edkvmn 3y agoHow will this approach work with larger teams?
- perrygeo 3y agoThat's a good point, the alignment approach doesn't scale as the team grows from dozens to thousands. But the fundamental question isn't "how can we support ever larger teams" but "how can we create better software"? I don't see any evidence that "larger teams" produce fundamentally better outcomes.
- edkvmn 3y agoI can align with that, given my own experience. Going back to your original point, of alignment, how does that work in practice, with a diverse team of different expertise and experience level?