HN2new | past | comments | ask | show | jobs | submitlogin

+1

Sprints also have the pleasant effect of forcing some coherence onto work.

In the Old Days, teams might build software like a layer-cake: All the lowest layer, then the next layer, then the next, and so on to the top. So at the beginning, we’d be building infrastructure based on projections (a fancy word for “wild-ass guesses”) of what the subsequent layers would need.

You can, in theory, do that in sprints, but with an emphasis on delivering “working software,” sprints would help devs and stakeholders pick very small end-to-end increments and build whatever was needed to make them work.

This kept everyone focus on work that was known to be needed, and since you were building a complete increment, the team would be building the infrastructure at the same time it was designing and building the functionality relying on the infrastructure.

This kind of thing has its own failure modes, of course, but it eliminated a number of catastrophic project failure modes without even getting into the value of delivering working software sooner and revising priorities based on feedback.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: