I have a lot of issues with scrum and I think twitter post and the comments here touch on a lot of them, but one of my biggest annoyances with the whole thing that I hardly ever hear anyone mention is the term "sprints".
If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally break the marathon into small sections and sprint them all.
I know it seems minor (and it probably is), but it's always felt a bit telling that the recurring segment for work in scrum is named after something you cannot do repeatedly without completely burning yourself out.
“One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions.
I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything.
I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova.
I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...
“My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, https://news.ycombinator.com/item?id=20017854#20021832
“I regularly ask ‘Why are we running a marathon in a thousand sprints?’.
Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for ‘high velocity’. There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.”—epage, https://news.ycombinator.com/item?id=20017854#20021832
Thanks for pointing this and I don't believe this is a minor point. I'm managing multiple teams - I was a developer - and I consider the "long" time perspective as a product quality technically speaking and also the team health. And a sprint is not compatible with those two last points where at the end of a sprint everybody in the team rush to deliver the user story and everybody is exhausted or tired...
Completely agree, it has always bothered me as well. To me it (strongly) implies rushing, and I don't believe that constantly keeping your team in a stressful state where you are always rushing or 'sprinting' towards the next goal is a good sustainable long-term strategy.
If the word (sprint) is a problem, then change it. Call it "iteration", "segment", whatever.
Taking a 500km bicycle ride from one place to another, you surely will plan the thing as segments. I would plan days and see where I can reach milestones: a city, a place to stay, a sight-seeing place, a mountain top, a ferry, a destination...
A software development project of several months is not a Marathon.
I've run a Marathon in a few hours. But even in a Marathon I look at my starting preparations of the day, my 5km times, reach the half marathon, plan for the drinking stops, plan when my primary energy source is depleted, how to get over it, ... Few people run a Marathon from front to end with the same speed&energy, without a plan how to mentally split up the race.
I agree that a word is just a word and it can easily be changed. That's why I called it a minor issue. I think my issue is more that if we have a framework where part of the framework is named after something that is not unsustainable long term, it makes me question the goals and intent of the people who created it. I have to ask myself, "are we using this in an unintended way".
It's like if you came to my house and asked for a towel and I went, "oh yeah, use my butt towel". Just because it's called a butt towel doesn't mean it's actually got anything to do with a butt, but you're probably going to be a bit uncomfortable until you understand why I'm calling it that.
If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally break the marathon into small sections and sprint them all.
I know it seems minor (and it probably is), but it's always felt a bit telling that the recurring segment for work in scrum is named after something you cannot do repeatedly without completely burning yourself out.