Re:Chrome was delivered without any sprints at all (2021)
by coldtea on Wednesday August 16, 2023 @10:29AM
(#37147594)
>They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. Sprints are just a way of breaking up work into discrete periods of time.
That's already the same as saying "A, B, and C parts will be done in that period of time, then C, D, E, F" and so on.
So you already pressupose what's to be done by when. And even if you roll-over tasks that haven't been completed to the next sprint, you still have this concept of falling behind (which is what "talking about why you failed the Sprint doing the retro" reinforces - and that invariably will lead to death marches and the fool's errand of "doing a better job of allocating work in the next sprint").
Whereas what they describe is "A (or B or C...) will be done when it is done, and the same holds for the whole project".
So they work everyday 9-5, give it their best shot, and it is completed day by day, with no arbitrary deadline to have A, B, C parts completed by.
If by using sprints you're going to do the exactly same thing (just work 9-5 everyday, and your project is ready when it's ready), then you don't need sprints.
Sprints only make sense when you don't plan on doing that, but to use them as a yardstick of being on some schedule or falling behind, and as a way to force developers to work overtime to "keep up with the planning".
That's already the same as saying "A, B, and C parts will be done in that period of time, then C, D, E, F" and so on.
So you already pressupose what's to be done by when. And even if you roll-over tasks that haven't been completed to the next sprint, you still have this concept of falling behind (which is what "talking about why you failed the Sprint doing the retro" reinforces - and that invariably will lead to death marches and the fool's errand of "doing a better job of allocating work in the next sprint").
Whereas what they describe is "A (or B or C...) will be done when it is done, and the same holds for the whole project".
So they work everyday 9-5, give it their best shot, and it is completed day by day, with no arbitrary deadline to have A, B, C parts completed by.
If by using sprints you're going to do the exactly same thing (just work 9-5 everyday, and your project is ready when it's ready), then you don't need sprints.
Sprints only make sense when you don't plan on doing that, but to use them as a yardstick of being on some schedule or falling behind, and as a way to force developers to work overtime to "keep up with the planning".