3 ms·

> They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. I don't think so. That's why sprints are so toxi

by jjav 3y ago

> They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. I don't think so. That's why sprints are so toxic. It's even right in the name. A 100m run is a "sprint", but nobody expects you to maintain that pace for a marathon. Much less for a multi-decade career. But in software you're expected to be in a sprinting pace all life long. And even increasing your "velocity" constantly. If that's not a death march, what is. > Sprints are just a way of breaking up work into discrete periods of time. There is not rational purpose to this. If the work takes 4 days, there's no reason to fabricate an artificial sprint boundary that forces you to break it down into two 2-day tasks just to fit into the confines of this imaginary sprint. It'll still be done four days from now.

kanzenryu2 3y ago
The name sprint comes from rugby, and just refers to what the team would be doing together to succeed (sprinting to the other end of the field with the ball).
- verve_rat 3y ago
  So what part is the dirty ruck where the people on the bottom get their eyes gouged, their heads stomped, and their nut sacks torn open?
mjfisher 3y ago
The rational purpose is this: sprints should be a way of trading off lower utilisation for more predictable delivery. However, your example is unrealistic - you wouldn't split that task into two. If it won't fit comfortably in the sprint it waits for the next one. It varies hugely by team and process, but where scrum/sprints are a good fit a reasonable first level of sprint loading seems to be a limit at about 70%. E.g. if an engineer has ten days available to work in a sprint, no more than 7 days of estimated work are pushed their way. The other 30% is assumed to be code reviews, meetings, pairing, bugfixing etc. If that 70% is too high or low, it can be adjusted. For everything else, there's Kanban.
- jjav 3y ago
  > If it won't fit comfortably in the sprint it waits for the next one. That will never be how it's done. You work on it however long you can on this sprint and then finish it in the next one. So now you have two choices: either break it down in a completely arbitrary way into two stories, one for each sprint. Or just completely ignore the sprint boundary nonsense and just work on it. Either way, it highlights how dumb it is to put silly boundaries on work delivery. Accomplishes nothing other than to waste people's time.
  - mjfisher 3y ago
    Sorry, but that blanket statement is just wrong. That is _exactly_ how it's done when I run a scrum team. If it stops being a good fit or working well for any number of reasons, we stop and look at the process. It works because your stakeholders see that you're actually delivering what you said you would _when_ you would, and that gets you the buy in and authority to run the team in a sane and sustainable manner. For what it's worth, I prefer Kanban in most cases - but both are just different ways of managing WIP, utilisation and delivery time.
memefrog 3y ago
You're confusing etymology and meaning. The fact that 'sprint', in completely different usage, has that meaning, does not mean any of that connotation carries over to this context. There is a clear rational purpose to breaking tasks up into parts. There are atomic units of work. Very few tasks can't be broken up into two-week segments.
Cthulhu_ 3y ago
But the term "sustainable pace" is also mentioned a lot in the literature. An increase in velocity does NOT mean "work harder"; an increase in velocity should come natural as your codebase expands, you get more reusable components, your team gains experience, etc. Example. New feature, estimated at 5 story points. One part is a button, takes you half a day to build it. Next feature, very similar to the other one, 5 story points. But this time you have a button component already, so you can just reuse it. Same points delivered, less time spent, meaning you have time to pick up another story, meaning your velocity goes up. Nobody, least of all proponents of scrum / agile methodologies, is saying that you should work harder, do a death march, etc. It acknowledges that software development is an infinite and long term process. Scrum does NOT work with deadlines. It works with predictability; your team's average velocity and the story points of upcoming stories are known, it's then up to the product owner to set priorities if they need a feature live at a certain point in time. Missed deadlines then become bad planning and prioritization more than employees not working fast enough. > There is not rational purpose to this. Just to highlight this: The rational purpose to sprints is for project management to be able to look ahead and be able to say "we expect this feature to be done in X weeks time". It doesn't mean that a 4 day task should be done in 2 weeks. A sprint is just a unit of time, it isn't a promise.
- sirwhinesalot 3y ago
  > Next feature, very similar to the other one, 5 story points. But this time you have a button component already, so you can just reuse it. Same points delivered, less time spent, meaning you have time to pick up another story, meaning your velocity goes up. This makes absolutely no sense to me and it is not how we do things at work. When the second task is estimated it will get a story point count of 1 because it's just copy pasting a button, not 5 which requires implementing a button from scratch.
- 9659 3y ago
  "an increase in velocity should come natural as your codebase expands" you may not respect academic software engineering, but if this is true you have just created a perpetual motion machine. changing / adding software to a system becomes more expensive (takes more time) as the size of the system increases. and it is not linear.
eternityforest 3y ago
The purpose, as I've seen(I've never done true formal agile but I think it influenced some of the people I worked) is that some businesspeople seem to like to see constant visible progress. 4 days is too long for them to wait, they get antsy and think nothing is happening if you can't actually show them something they can understand in a day or two. I think it actually affects the code, everything has to be taped together tiny bits, because you can never do anything that doesn't show results fast, so you if you need a framework or an architecture or a plugin system, it's really hard. But agile says that's fine because you're going to be doing first drafts and throwing away code anyway....

by jjav 3y ago

kanzenryu2 3y ago

The name sprint comes from rugby, and just refers to what the team would be doing together to succeed (sprinting to the other end of the field with the ball).

verve_rat 3y ago
So what part is the dirty ruck where the people on the bottom get their eyes gouged, their heads stomped, and their nut sacks torn open?

mjfisher 3y ago

The rational purpose is this: sprints should be a way of trading off lower utilisation for more predictable delivery. However, your example is unrealistic - you wouldn't split that task into two. If it won't fit comfortably in the sprint it waits for the next one. It varies hugely by team and process, but where scrum/sprints are a good fit a reasonable first level of sprint loading seems to be a limit at about 70%. E.g. if an engineer has ten days available to work in a sprint, no more than 7 days of estimated work are pushed their way. The other 30% is assumed to be code reviews, meetings, pairing, bugfixing etc. If that 70% is too high or low, it can be adjusted. For everything else, there's Kanban.

jjav 3y ago
> If it won't fit comfortably in the sprint it waits for the next one. That will never be how it's done. You work on it however long you can on this sprint and then finish it in the next one. So now you have two choices: either break it down in a completely arbitrary way into two stories, one for each sprint. Or just completely ignore the sprint boundary nonsense and just work on it. Either way, it highlights how dumb it is to put silly boundaries on work delivery. Accomplishes nothing other than to waste people's time.
- mjfisher 3y ago
  Sorry, but that blanket statement is just wrong. That is _exactly_ how it's done when I run a scrum team. If it stops being a good fit or working well for any number of reasons, we stop and look at the process. It works because your stakeholders see that you're actually delivering what you said you would _when_ you would, and that gets you the buy in and authority to run the team in a sane and sustainable manner. For what it's worth, I prefer Kanban in most cases - but both are just different ways of managing WIP, utilisation and delivery time.

memefrog 3y ago

You're confusing etymology and meaning. The fact that 'sprint', in completely different usage, has that meaning, does not mean any of that connotation carries over to this context. There is a clear rational purpose to breaking tasks up into parts. There are atomic units of work. Very few tasks can't be broken up into two-week segments.

Cthulhu_ 3y ago

But the term "sustainable pace" is also mentioned a lot in the literature. An increase in velocity does NOT mean "work harder"; an increase in velocity should come natural as your codebase expands, you get more reusable components, your team gains experience, etc. Example. New feature, estimated at 5 story points. One part is a button, takes you half a day to build it. Next feature, very similar to the other one, 5 story points. But this time you have a button component already, so you can just reuse it. Same points delivered, less time spent, meaning you have time to pick up another story, meaning your velocity goes up. Nobody, least of all proponents of scrum / agile methodologies, is saying that you should work harder, do a death march, etc. It acknowledges that software development is an infinite and long term process. Scrum does NOT work with deadlines. It works with predictability; your team's average velocity and the story points of upcoming stories are known, it's then up to the product owner to set priorities if they need a feature live at a certain point in time. Missed deadlines then become bad planning and prioritization more than employees not working fast enough. > There is not rational purpose to this. Just to highlight this: The rational purpose to sprints is for project management to be able to look ahead and be able to say "we expect this feature to be done in X weeks time". It doesn't mean that a 4 day task should be done in 2 weeks. A sprint is just a unit of time, it isn't a promise.

sirwhinesalot 3y ago
> Next feature, very similar to the other one, 5 story points. But this time you have a button component already, so you can just reuse it. Same points delivered, less time spent, meaning you have time to pick up another story, meaning your velocity goes up. This makes absolutely no sense to me and it is not how we do things at work. When the second task is estimated it will get a story point count of 1 because it's just copy pasting a button, not 5 which requires implementing a button from scratch.
9659 3y ago
"an increase in velocity should come natural as your codebase expands" you may not respect academic software engineering, but if this is true you have just created a perpetual motion machine. changing / adding software to a system becomes more expensive (takes more time) as the size of the system increases. and it is not linear.

eternityforest 3y ago

The purpose, as I've seen(I've never done true formal agile but I think it influenced some of the people I worked) is that some businesspeople seem to like to see constant visible progress. 4 days is too long for them to wait, they get antsy and think nothing is happening if you can't actually show them something they can understand in a day or two. I think it actually affects the code, everything has to be taped together tiny bits, because you can never do anything that doesn't show results fast, so you if you need a framework or an architecture or a plugin system, it's really hard. But agile says that's fine because you're going to be doing first drafts and throwing away code anyway....