Does it ever occur to Scrum people that it’s not a good idea to spend your entire life in a mad state of sprinting? Marathon runners don’t sprint 100m, then sprint another 100m, repeatedly, to cover the distance of a race.
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.)
Why's it have to be a marathon in your mind? Any race - doesn't have to be that literal.
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.)
In that story the messenger running the marathon collapses and dies soon after coming back to Athens.
https://en.wikipedia.org/wiki/Pheidippides
Maybe the analogy is not so different :)
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)
> 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.
And it's a competitive sport. It might not be healthy, but that's how you win.
A hiker or a marathon runner or a club cyclist not currently at an event have a destination: where they started. But the good stuff happens in the middle, and that’s not necessarily planned out in advance.
Pacing is even more important then because there may be nobody to come bail you out, or it might take hours for them to do so.
Hell, in this analogy even the marathon organizers don't know the destination. Or much care.
If you started making a task-tracking app, and after all the work for scrum end up building a video game instead, something has gone terribly wrong.
Instead of using an SDLC methodology here, use one of the relevant product frameworks for that, but needless to say, there is a large element of luck here, as finding a PM/F isn't guaranteed.
Usually you use low-tech SDLCs like Scrum/SAFe at the places that already have found PM/F, or those relying on violence (aka "taxation") as their main business model (e.g. military/government/public sector).
The only PM/F Scrum Inc found is how to make bazillions from useless certifications and training.
--
[1] Scrum | Dr Jeff Sutherland | Talks at Google
But sprints are often a reasonable step especially for teams that are part of a large organization. It is often easier (and faster) to move a team from waterfall to sprints to a pull system than it is to go from waterfall to a pull system directly.
NOTE: informal SDLCs, mini-waterfall, and RUP are not classical waterfall.
Agile™/Scrum® consultants implanted false memories to so many people. My colleagues who worked with me under lightweight flavor of RUP using an incremental approach, after getting Scrum Master certification now referring to it as "waterfall" ;)
There is a third approach: to give autonomy to the team so that it can distribute and perform tasks as it sees fit. There may be hints about priorities, such as a must-to-have or nice-to-have. See: Shape Up Method or Informal Mini Waterfall SDLC (design->plan->build(iteration)->ship) used by FAANG.
Once you have a written design document (especially if you wrote it yourself), you don't need a ticketing system like Jira. In many places we have only used tickets for bug reports and not for tasks.
You could measure engagement, conversion, churn, or any other meaningful metric. The main point is shortening feedback cycle.
There usually is a customer. It may not be the person who is called the customer, but somewhere there is someone who is spending money on development and is wanting to be able to us or benefit from whatever is being produced.
If the customer doesn't have time to collaborate with the devs to provide feedback, it might be a sign that what is being built isn't valuable to them. This could be either because it doesn't address a real need or because the cycle time is so slow it isn't going to help them any time soon. When a dev team is working on the customer's biggest pain point and has a track record of delivering a solution in a few days, customers will magically have time to talk about it.
Now imagine a marathon run by a drunk monkey who changes the route on a whim every 30 minutes.
Who wins, the sprinters who sprint for 30 minutes and check where the next target is or the marathon runners who are still going by the original plan?