3 ms·

Sure, but if you plan out 10 milestones two weeks apart, is that not just "waterfall" at that point? To be sure, my main point is to disagree that sprints help

Sure, but if you plan out 10 milestones two weeks apart, is that not just "waterfall" at that point? To be sure, my main point is to disagree that sprints help hit deadlines. They might even hurt. For example. I'm not sure if that failure mode is really changed via sprints. if you get 10 months in, and 15% left, nothing changes that it could still take a year. Further, the sprints discourage lifting your head up to unblock, design and plan that 15% before you actually start on it. So seems a bit waterfall like to feel incremental stuff was getting done, but you still underscored that last 15%, and sprints encourage you to realize that very late in the game. I think a big flaw in scrum is error analysis of expected completion dates. Instead of compounding uncertainty across sprints, often that velocity is given no error bars and is linearly extrapolated months into the future (and in a perverse way increases estimate precision erroneously).

pas 4y ago
So I've written an example in a comment here https://news.ycombinator.com/item?id=32507364 https://news.ycombinator.com/item?id=32507364 , but to try to emphasize the difference between waterfall and, um, non-waterfall is that historically (as far as I know) the scope was fixed in waterfall (and releases just got delayed more and more), whereas agile (based on "extreme programming" right?) says the opposite. Release often, in time-fixed increments, and try to always release something working that slowly but surely approximates the end goal. This of course implies that there's an end goal (so it's not surprising that there's a rough plan with so and so many milestones already laid out), but allows for moving that goal. Of course, as I vehemently argued in that comment, doing this by force in a top-to-bottom way, spending more time chasing this constantly moving end goal in planning session, than actually working on delivering something is a folly. (Of course there are very turbulent situations where a small company/group fights for its own survival, pivots every second week to something else, throws out half of the existing stack every quarter, etc.. etc... but in that case the problem is not with "agile". The problem is trying to do something that has clearly no market traction without sufficient money and a sane business plan.)

pas 4y ago

So I've written an example in a comment here https://news.ycombinator.com/item?id=32507364 https://news.ycombinator.com/item?id=32507364 , but to try to emphasize the difference between waterfall and, um, non-waterfall is that historically (as far as I know) the scope was fixed in waterfall (and releases just got delayed more and more), whereas agile (based on "extreme programming" right?) says the opposite. Release often, in time-fixed increments, and try to always release something working that slowly but surely approximates the end goal. This of course implies that there's an end goal (so it's not surprising that there's a rough plan with so and so many milestones already laid out), but allows for moving that goal. Of course, as I vehemently argued in that comment, doing this by force in a top-to-bottom way, spending more time chasing this constantly moving end goal in planning session, than actually working on delivering something is a folly. (Of course there are very turbulent situations where a small company/group fights for its own survival, pivots every second week to something else, throws out half of the existing stack every quarter, etc.. etc... but in that case the problem is not with "agile". The problem is trying to do something that has clearly no market traction without sufficient money and a sane business plan.)