3 ms·

That's always bugged me as a broken analogy, too. In college it was an extremely common aphorism "It's a marathon, not a sprint" as reminder to sustainably pac

That's always bugged me as a broken analogy, too. In college it was an extremely common aphorism "It's a marathon, not a sprint" as reminder to sustainably pace yourself and it has always seemed like Scrum originators had heard that phrase and gotten it exactly backward and it stuck. In marathon pacing analogy terms, "Split" would be the more accurate term. Though I know a lot of people don't think that sounds as good as "Sprint" does. Personally, I've often preferred just calling them "Fortnights" as an accurate description for "two-week process" (and a useful callback to long watches in older times). (Though the game "Fortnite" has confused that term a bit recently among the youth. "What does this have to do with the shooter?" Sigh.)

chrisseaton 4y ago
Maybe a 'lap'.
- WorldMaker 4y ago
  The original legendary Marathon was a run between the cities of Marathon and Athens. No loops in that course to consider "a lap". 'Lap' doesn't fit the analogy quite right either. (Some modern street Marathons do use lapping courses today, but that is more for simplifying the logistics of getting people back to their cars and such from the finish line as anything proper to the "form" of a Marathon.)
  - chrisseaton 4y ago
    > The original legendary Marathon was a run between the cities of Marathon and Athens. Why's it have to be a marathon in your mind? Any race - doesn't have to be that literal.
    - WorldMaker 4y ago
      The reason for picking a marathon as the specific analogy, which Scrum intended to do (but got backwards) is that: 1) It's a (very) long haul. Pacing yourself is mandatory. (In most of the legends of the first marathon, the runner collapsed to the death after delivering his message in Athens.) 2) It's explicitly an A to B with a long-term goal in mind. From software product idea to finished software, in theory. (This part of the Scrum analogy has largely been forgotten/ignored/killed of course in the modern view of software as a constant Ship of Theseus that is never finished and always has infinite backlog.) 3) Pacing yourself while running a marathon consists of breaking your run into smaller time boxes. Most runners do plan specific paces for different "splits" within a marathon. Some runners pay coaches lots of money to try to come up with these plans. (Again, here Scrum screwed up the analogy by using the exact wrong term, "Sprint": a short fast race where pace is as fast as possible, and no need to think about "the next mile" after the "Sprint".) 4) The type of race doesn't change in a marathon. A triathlon might make a similarly good long haul project development metaphor if you have to shift entirely different contexts every so often (swimming, biking, running), but software development doesn't (necessarily) have drastic context switches like that. "Mile to mile" ("week to week") in software development you are still largely doing the same tasks. I kind of agree with the Scrum originators that the marathon was a good analogy for software development projects. I just wish they hadn't immediately broken the analogy by getting fundamentals wrong like the relationship between Marathons and Sprints. (ETA: I'm not myself a runner. Most of what I know is from siblings and friends and trying to be a good sideline supporter.)
  - mejutoco 4y ago
    > The original legendary Marathon was a run between the cities of Marathon and Athens. In that story the messenger running the marathon collapses and dies soon after coming back to Athens. https://en.wikipedia.org/wiki/Pheidippides https://en.wikipedia.org/wiki/Pheidippides Maybe the analogy is not so different :)
isitmadeofglass 4y ago
The point of a sprint is that you shouldn’t sustain your pace. You should reach a given point and stop. The problem is that far to many programmers “sustain their pace” by implementing 1/3 of 4 things in 2 weeks instead of finishing a single thing completely. That’s not a problem in waterfall if your 100% sure that those 4 things will have to be complete over the course of 30weeks, but in scrum you are trying to deliver small increments to your customer to have them validated so you don’t spend 30 weeks on something that ends up not meeting client expectations(even if it does meet specified requirements exactly)
- WorldMaker 4y ago
  Of course, Scrum is concerned with sustainable pacing: avoiding end of waterfall "crunch", setting estimation horizons that are sustainable (developers are terrible at estimating things in two-week time periods, but developers have an impossible time estimating anything beyond that), modest attempts at preventing burn out, even regular "small increment" delivery is itself an attempt at sustainable pacing (rather than big blow out quarterly releases, for instance). > You should reach a given point and stop. "And stop"? I would almost pay to see a Scrum team that allows front-loading stories and pays for time off if they are completed ahead of sprint deadlines. That sounds like an incredible unicorn. There's no stopping in Scrum. There's always "pick a new story off the backlog" and there's always an infinite backlog to pick from, in my experience.

chrisseaton 4y ago

Maybe a 'lap'.

WorldMaker 4y ago
The original legendary Marathon was a run between the cities of Marathon and Athens. No loops in that course to consider "a lap". 'Lap' doesn't fit the analogy quite right either. (Some modern street Marathons do use lapping courses today, but that is more for simplifying the logistics of getting people back to their cars and such from the finish line as anything proper to the "form" of a Marathon.)
- chrisseaton 4y ago
  > The original legendary Marathon was a run between the cities of Marathon and Athens. Why's it have to be a marathon in your mind? Any race - doesn't have to be that literal.
  - WorldMaker 4y ago
    The reason for picking a marathon as the specific analogy, which Scrum intended to do (but got backwards) is that: 1) It's a (very) long haul. Pacing yourself is mandatory. (In most of the legends of the first marathon, the runner collapsed to the death after delivering his message in Athens.) 2) It's explicitly an A to B with a long-term goal in mind. From software product idea to finished software, in theory. (This part of the Scrum analogy has largely been forgotten/ignored/killed of course in the modern view of software as a constant Ship of Theseus that is never finished and always has infinite backlog.) 3) Pacing yourself while running a marathon consists of breaking your run into smaller time boxes. Most runners do plan specific paces for different "splits" within a marathon. Some runners pay coaches lots of money to try to come up with these plans. (Again, here Scrum screwed up the analogy by using the exact wrong term, "Sprint": a short fast race where pace is as fast as possible, and no need to think about "the next mile" after the "Sprint".) 4) The type of race doesn't change in a marathon. A triathlon might make a similarly good long haul project development metaphor if you have to shift entirely different contexts every so often (swimming, biking, running), but software development doesn't (necessarily) have drastic context switches like that. "Mile to mile" ("week to week") in software development you are still largely doing the same tasks. I kind of agree with the Scrum originators that the marathon was a good analogy for software development projects. I just wish they hadn't immediately broken the analogy by getting fundamentals wrong like the relationship between Marathons and Sprints. (ETA: I'm not myself a runner. Most of what I know is from siblings and friends and trying to be a good sideline supporter.)
- mejutoco 4y ago
  > The original legendary Marathon was a run between the cities of Marathon and Athens. In that story the messenger running the marathon collapses and dies soon after coming back to Athens. https://en.wikipedia.org/wiki/Pheidippides https://en.wikipedia.org/wiki/Pheidippides Maybe the analogy is not so different :)

isitmadeofglass 4y ago

The point of a sprint is that you shouldn’t sustain your pace. You should reach a given point and stop. The problem is that far to many programmers “sustain their pace” by implementing 1/3 of 4 things in 2 weeks instead of finishing a single thing completely. That’s not a problem in waterfall if your 100% sure that those 4 things will have to be complete over the course of 30weeks, but in scrum you are trying to deliver small increments to your customer to have them validated so you don’t spend 30 weeks on something that ends up not meeting client expectations(even if it does meet specified requirements exactly)

WorldMaker 4y ago
Of course, Scrum is concerned with sustainable pacing: avoiding end of waterfall "crunch", setting estimation horizons that are sustainable (developers are terrible at estimating things in two-week time periods, but developers have an impossible time estimating anything beyond that), modest attempts at preventing burn out, even regular "small increment" delivery is itself an attempt at sustainable pacing (rather than big blow out quarterly releases, for instance). > You should reach a given point and stop. "And stop"? I would almost pay to see a Scrum team that allows front-loading stories and pays for time off if they are completed ahead of sprint deadlines. That sounds like an incredible unicorn. There's no stopping in Scrum. There's always "pick a new story off the backlog" and there's always an infinite backlog to pick from, in my experience.