5 ms·
The author is using the word a bit differently, but the fact that "sprint" has been normalized as a unit of work for software development, and developers are ex
by thrwy_918 4y ago
The author is using the word a bit differently, but the fact that "sprint" has been normalized as a unit of work for software development, and developers are expected to be in a "sprint" more or less at all times, has always been a source of the deepest absurdity to me.
A "sprint" is, almost by definition, a pace that's sustainable only for short periods. The fact that developers are expected to perform sprint after sprint endlessly, to view "sprint" as the default baseline pace, seems a ludicrous abuse of language.
- butlerm 4y agoIt certainly implies developers recovering for several days between sprints.
- throwaway821909 4y agoI think the language is accurate and that's the problem (or not depending on your perspective) - sprints are all or nothing, and a way to create an artificial sense of urgency. "It's the last day of the sprint, better work late/cut corners because 99% done is failure". And then if you do your reward is one more work item next sprint, to ensure everyone is working as hard as possible all the time.
- slim 4y agoif memory does not fail me, original sprint was 3 weeks long followed by "spare" time till the end of the month (mostly meetings, planning, review, etc..)
- paulryanrogers 4y agoWas the word 'sprint' chosen to describe a never ending crunch? Or just to roughly imply quick forward motion. Unlike waterfall that often slows for large portions of time until the next sudden and irreversible release? Perhaps it would've been more accurate to use something like 'unit' in education. Which is just a subdivision of time and effort roughly equal to a week or two.
- crazygringo 4y agoI think you're being overly literal with "sprint". And no, developers are not expected to be "in a sprint more or less at all times". To the contrary -- in between each sprint, there's a review, a retrospective, often a weekend, then regrouping and feature analysis, planning poker, decision on which features to impement, and getting it up on the board. That's the whole point. Instead of a long marathon without revision/reassessment/regrouping, it's a series of short sprints interspersed with revision/reassessment/regrouping. The metaphor here is the distance traveled, not the speed. Sprints are shorter distances, that's all. Nobody has ever intended "sprint" to mean that engineers are going faster than in a marathon, anymore than "waterfall" means engineers are all tumbling down white water to their deaths at the bottom. :)
- stormbrew 4y ago> To the contrary -- in between each sprint, there's a review, a retrospective "in between" is overstating things a bit. The current norm seems to be two week sprints and all these things are done at the beginning and end of them. To be honest, I personally do feel like this gives the feeling of 'sprinting' because it usually means at least 2-3 days of the sprint are 'wasted' on meetings and that counts for a lot when it's 2/10 or 3/10. And a lot of the terminology around this kind of process are geared to give you a sense of urgency. Right back to "Extreme Programming".
- vosper 4y ago> The current norm seems to be two week sprints and all these things are done at the beginning and end of them. Everywhere I've worked that did "agile" did it this way. The ending of a sprint is always the start of the next one; teams are always in a sprint. If that part of the process can't be changed or removed then one of the best things to do is decouple the sprint cadence from other events. Eg don't put demo, pointing, planning, and retro on the same day. Try to do pointing mid-sprint, if you know what's coming up, so that you're not cramming it in at the end. Don't release to staging/prod at sprint boundaries, do that mid-sprint. The worst is to clump all the meetings, distractions, and stresses together.
- dboreham 4y agoAbsurdity abounds in the field, in my lengthy experience.
- benreesman 4y agoI've always chuckled at the nomenclature that's crept in around software development. You've got "agile", "sprint", "scrum", "extreme programming", "sustainable pace", and probably other athletic metaphors I'm forgetting. There are various kinds of "stories", often combined into "epics", "retrospectives", "personas" and other literary metaphors that I'm likely forgetting. "Track Star" and "Literature Major" are not stereotypes that I recall from my peers getting started in software, back then I didn't know many other computer nerds who had done more sports than my half-hearted JV swim and football, which is pretty weak. We for the most part had all been spending way too much time in front of the computer to be truly serious about athletics and literature. But I'm old, and times change (which is a good thing). Of course it would also be darkly funny if a bunch of literate athletes invaded the software business when it became lucrative/high-status and immediately started fogging up the windshield with a bunch of vague metaphors to obscure their lack of technicality. Who knows.
- throwaway892238 4y agoIt is a poor choice of word. But what's interesting to me is nobody notices the end and beginning of sprinting requires rest, regrouping, planning, getting ready. You can't just stop sprinting and start sprinting the next day like you're ready for a brand new race. Sprints should require reflection, a re-set, getting prepared. Instead it's just "the next 2 weeks of the same bullshit", without proper preparation, without clearing the schedules to allow for streamlined work. When sprinting, any bump in the road can make you stumble, losing the race. We need more focus on clearing the bumps out of the road before a sprint.
- mdemare 4y agoMaybe “laps” would have been a better word than “sprints”?