4 ms·

What does “sprints are involuntary” mean? My team chooses the characteristics of the sprint. It’s not like they are randomly assigned. It’s a collaboration bet

What does “sprints are involuntary” mean? My team chooses the characteristics of the sprint. It’s not like they are randomly assigned. It’s a collaboration between leadership, team members and non-team stakeholders. It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense. What’s the alternative proposed? I wonder how the author is working if they think that these things are involuntary. It seems like their environment sucks and it’s expressed through saying scrum sucks. Scrum is so generic it can be adapted for many needs. I’d like to see the author explain why their scrum is so rigid. Does he suck at estimating? Suck at communicating? Lacks resources? Leadership is poor at estimating? Who knows, but it seems like blaming scrum is like blaming software development in general and more of a “this job would be great if it wasn’t for the customers” type screaming into the void.

nottorp 2y ago
> My team chooses the characteristics of the sprint. It’s not like they are randomly assigned. It’s a collaboration between leadership, team members and non-team stakeholders. It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense. But then it's not Scrum. Scrum is weekly.
- naavis 2y ago
  I don't think anything in Scrum dictates iterations must be one week long. https://www.scrum.org/learning-series/what-is-scrum/ https://www.scrum.org/learning-series/what-is-scrum/
  - freedomben 2y ago
    No dictation on length, but the length is supposed to be consistent. If you want to take a three week sprint or something instead because the feature makes sense, you mess up a whole lot of things, especially the metrics. And, let's be honest, the metrics are the biggest reason why management imposes Scrum. They want to be able to quantify everyones contribution down to hard numbers that they can then use to know how everyone is performing. If you screw up the metrics, it won't take long for someone to step in and "get your team back on track."
    - ebiester 2y ago
      Metrics and software process are orthogonal. Now, you can argue that consistent processes across teams is used to enable metrics, but Taylorism is going to creep up any place that has management that has been infected by it.
- ebiester 2y ago
  "They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint." - scrumguides.org You also need to understand that "release" might mean behind a feature flag. Further, while continuous integration is not within the Scrum guide, it is a common practice in Scrum teams. Yes, there is a concept of a sprint goal, but the sprint goal may be a subset of the product goal. You may choose to group increments across sprint boundaries to present to customers independently of the end of the sprint.
- prepend 2y ago
  Scrum is not necessarily weekly. You can pick any period for the sprint length. I think I’ve seen two week as the most typical.
teeray 2y ago
> My team chooses the characteristics of the sprint. It’s not like they are randomly assigned...It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense. Count your blessings. This is not the case everywhere.
freedomben 2y ago
If you are working in a place that lets your team pick the sprint length each time based on how long you think it should be for the work you're doing, that is absolutely not typical. You seem to be either taking your anecdotal experience with what was called "scrum" and projecting it back onto the spec. Or, redefining "scrum" to be what you think it should be, not what it is. Incidentally, I find nearly everyone who defends scrum does the same thing. It's a continual No True Scotsman that gets to the point where "scrum" becomes meaningless. I actually blame the Scrum people for that because there's a ton of things that are guidelines rather than rules, although the ultimate decision is with the ScrumMaster or PM, so the level of flexibility of the Scrum implementation is dependent on the benevolence of this ScrumMaster®. I worked as a consultant for several years and have been at many different startups, so I've experienced a lot of different flavors of Scrum, and the effectiveness varies widely. There are Scrum implementations that are authoritarian hell-holes where devs are just mice on wheels, and there are some that are pretty good. The problem is, both are still "scrum." So it's a lot like saying "monarchy is good" or "monarchy is bad." Well, it depends a lot on the monarch, but the system itself gives an enormous amount of control to one (or a few) people, and then it's up to that person to divvy out autonomy as they see fit. You might get a benevolent ruler who gives autonomy, but you might not, and both fall under the system.
- prepend 2y ago
  I’ve never had variable sprint lengths, but picking the internal is exactly how I’ve done agile for years. The whole point, I thought, is that you’re just frequently releasing so you want some fixed interval rather than adjusting it based on workload. Pick work that fits into the time period, not the other way around.
rickdeckard 2y ago
I don't know which process you follow, but while sprints are created in collaboration, in mid/large organizations everything is supposed to be in-sync across departments (so you can align interdisciplinary tasks). In most cases I've seen, Agile basically introduces an additional company-internal clock with tick-tocks for days and weeks. To me the article correctly describes how agile is assumed to be somewhat abstracted from "real-world" time, but in reality it's just two other hands on the same clock with pressure and tasks still increasing close to "real-world" clock-events (launch-dates, exhibitions, customer-events,...)

nottorp 2y ago

> My team chooses the characteristics of the sprint. It’s not like they are randomly assigned. It’s a collaboration between leadership, team members and non-team stakeholders. It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense. But then it's not Scrum. Scrum is weekly.

naavis 2y ago
I don't think anything in Scrum dictates iterations must be one week long. https://www.scrum.org/learning-series/what-is-scrum/ https://www.scrum.org/learning-series/what-is-scrum/
- freedomben 2y ago
  No dictation on length, but the length is supposed to be consistent. If you want to take a three week sprint or something instead because the feature makes sense, you mess up a whole lot of things, especially the metrics. And, let's be honest, the metrics are the biggest reason why management imposes Scrum. They want to be able to quantify everyones contribution down to hard numbers that they can then use to know how everyone is performing. If you screw up the metrics, it won't take long for someone to step in and "get your team back on track."
  - ebiester 2y ago
    Metrics and software process are orthogonal. Now, you can argue that consistent processes across teams is used to enable metrics, but Taylorism is going to creep up any place that has management that has been infected by it.
ebiester 2y ago
"They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint." - scrumguides.org You also need to understand that "release" might mean behind a feature flag. Further, while continuous integration is not within the Scrum guide, it is a common practice in Scrum teams. Yes, there is a concept of a sprint goal, but the sprint goal may be a subset of the product goal. You may choose to group increments across sprint boundaries to present to customers independently of the end of the sprint.
prepend 2y ago
Scrum is not necessarily weekly. You can pick any period for the sprint length. I think I’ve seen two week as the most typical.

teeray 2y ago

> My team chooses the characteristics of the sprint. It’s not like they are randomly assigned...It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense. Count your blessings. This is not the case everywhere.

freedomben 2y ago

If you are working in a place that lets your team pick the sprint length each time based on how long you think it should be for the work you're doing, that is absolutely not typical. You seem to be either taking your anecdotal experience with what was called "scrum" and projecting it back onto the spec. Or, redefining "scrum" to be what you think it should be, not what it is. Incidentally, I find nearly everyone who defends scrum does the same thing. It's a continual No True Scotsman that gets to the point where "scrum" becomes meaningless. I actually blame the Scrum people for that because there's a ton of things that are guidelines rather than rules, although the ultimate decision is with the ScrumMaster or PM, so the level of flexibility of the Scrum implementation is dependent on the benevolence of this ScrumMaster®. I worked as a consultant for several years and have been at many different startups, so I've experienced a lot of different flavors of Scrum, and the effectiveness varies widely. There are Scrum implementations that are authoritarian hell-holes where devs are just mice on wheels, and there are some that are pretty good. The problem is, both are still "scrum." So it's a lot like saying "monarchy is good" or "monarchy is bad." Well, it depends a lot on the monarch, but the system itself gives an enormous amount of control to one (or a few) people, and then it's up to that person to divvy out autonomy as they see fit. You might get a benevolent ruler who gives autonomy, but you might not, and both fall under the system.

prepend 2y ago
I’ve never had variable sprint lengths, but picking the internal is exactly how I’ve done agile for years. The whole point, I thought, is that you’re just frequently releasing so you want some fixed interval rather than adjusting it based on workload. Pick work that fits into the time period, not the other way around.

rickdeckard 2y ago

I don't know which process you follow, but while sprints are created in collaboration, in mid/large organizations everything is supposed to be in-sync across departments (so you can align interdisciplinary tasks). In most cases I've seen, Agile basically introduces an additional company-internal clock with tick-tocks for days and weeks. To me the article correctly describes how agile is assumed to be somewhat abstracted from "real-world" time, but in reality it's just two other hands on the same clock with pressure and tasks still increasing close to "real-world" clock-events (launch-dates, exhibitions, customer-events,...)