5 ms·

They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. Sprints are just a way of breaking up work into dis

They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. Sprints are just a way of breaking up work into discrete periods of time. There’s nothing about them that implies “drama, broken marriages, or broken families”. If you don’t finish the work you had planned to during a sprint then you fail the sprint, talk about why during the retro, then do a better job of allocating work in the next sprint. You don’t ruin your marriage over it‽ As for the rest of it, it seems like you can summarise the whole thing as “it’s good to have experienced team members”? Sure, but I don’t see why that’s a particularly novel insight.

psunavy03 3y ago
And this is why many agilists prefer to use the term "iteration," because "sprint" can be conveniently "misinterpreted" by toxic managers.
- fredrikholm 3y ago
  On that very note: https://www.youtube.com/shorts/liUiRfN9NzQ https://www.youtube.com/shorts/liUiRfN9NzQ
audiodude 3y ago
At every former company, where we tried to use Agile or sprints, we ended up reaching a system where we just had basically "one big rolling sprint". Every two weeks, only a few tasks were actually done, and every task got pulled into the next "sprint". Combine this with the fact that we weren't delivering any artifacts at the end of the sprint, so we didn't have any feedback from stakeholders and weren't really iterating either.
- JimDabell 3y ago
  > we ended up reaching a system where we just had basically "one big rolling sprint". But there’s no such thing as “one big rolling sprint” though. If it’s “one big rolling…” then it can’t be a sprint. It’s like dehydrated water. It’s conceptually incoherent. To untangle the wording of this, when you say your process became “one big rolling sprint”, what you’re actually saying is that you stopped using sprints, aren’t you?
  - atoav 3y ago
    How can it be a sprint if nobody is running? /s
  - zo1 3y ago
    Also known as the No True Scotsman argument https://en.m.wikipedia.org/wiki/No_true_Scotsman https://en.m.wikipedia.org/wiki/No_true_Scotsman. "You weren't doing real Agile™". The only reason I'm posting this is because we have had similar things happen in almost every attempt at using sprints. They're just not suited for any sort of formal/business context where you don't have absolute and frankly religious buy-in to the concept.
    - 261582335426158 3y ago
      It is a fallacy only if in support of "Trying to use sprints will improve your organization", it would not be a fallacy if in support of "The benefit of sprints are real but only if used properly" where properly is defined in some clear a priori way.
    - JimDabell 3y ago
      The “No true Scotsman” fallacy is when you introduce unrelated criteria to disqualify something that would ordinarily be a member of a group. It’s perfectly reasonable to point out that somebody who was not born in Scotland, does not have Scottish family, does not hold any kind of British citizenship, and has never even set foot in Scotland is not, in fact, a Scotsman. That’s not a fallacy. A sprint is a discrete period of time in which discrete software development tasks happen. A “rolling sprint” is conceptually void. You can’t have a discrete period of time that lasts indefinitely any more than you can have dehydrated water. The “rolling” part and the “sprint” part are mutually exclusive. I’m not even saying that they weren’t “doing real Agile” – I’m pointing out that what is being described has literally no meaning at all. You can’t be good or bad at it because it’s a meaningless term.
      - tacozilla 3y ago
        The purpose of language is to communicate, and audiodude did that quite effectively given the fact I chuckled when I read their comment, because I knew exactly what they meant. A "rolling sprint" might be an oxymoron, but it certainly isn't conceptually void. It quite literally does have meaning considering I and many others clearly understood the point he was making through his personal anecdote.
- BaseballPhysics 3y ago
  Sounds like you would've been better off with kanban. Did you ever consider switching?
  - jimbob45 3y ago
    In my experience, the people choosing between Scrum and Kansan are not the ones participating in the Scrum/Kanban. Modern leadership attempts to take away as much agency as possible and wonders why everyone hates them.
    - js8 3y ago
      > Modern leadership attempts to take away as much agency as possible and wonders why everyone hates them. Not that I disagree, but I think it's not modern. In the past, it was probably simply much more accepted that the agency is taken away by authorities, that's just how life is. I think people grew much less tolerant of that recently (which honestly I think is a good development), and more willing to question authorities in general. The hate part then comes from nostalgia.
    - BaseballPhysics 3y ago
      First, that wasn't my question, nor was it you I was asking. But sure, let's go with this. Frankly, this reeks of empty cynicism and we can do better than that around here. Your experience is also far from universal. In my previous company I was part of the leadership core and not only did teams have agency to decide what process to use, we were actively encouraging teams to consider alternatives since our practices had become pretty frozen over time (old habits, etc). Maybe your problem is you just found yourself at shitty companies. The world is a big one out there.
- YZF 3y ago
  From my experience it can work. I've worked on a team where we got really good at estimating, had really useful planning sessions, a good backlog. Worked pretty well and had some advantages in terms of getting the team to be engaged and take ownership. The problem with Agile in general is that it can easily be twisted around to make anything you want. A great team doesn't need agile methods, but it can use them and still be great, and possibly even get some improvement with careful use. Agile intended to fix organizations but organizations don't want to be fixed, and certainly not by a bunch of software people...
- ssss11 3y ago
  In my experience I’ve found (1) some teams don’t embrace it, (2) some teams don’t break down large tasks or (3) it’s not suited to the work. Each of these result in your rolling sprint. I absolutely hate seeing buzzwords for the sake of them but often the work simply doesn’t work well with sprints.
- Cthulhu_ 3y ago
  That sounds like a lack of discipline and retrospection. This is also the problem I have with scrum; people don't stick to the process, and cite how the agile manifesto says that the process isn't important. But this is a misconception. Stick to the process (religiously) at first, then assess how it works. In this case: you did not meet your sprint goals, which either meant you overcommitted (meaning the next sprint you pick up less work), the tasks did not meet the definition of ready (that is, they could not be finished in a single sprint), or you had impediments that weren't solved on time. All of those need to be spoken out loud during a retrospective session, and action undertaken. Not having any artifacts isn't the issue, you still need to set a moment to stop your work, review what has been done, consider what went well and what could be better, learn and improve. If the learning is that scrum doesn't work for you - and you can show that you did it properly - then there's other processes that might work better for you, as suggested.
  - lloydatkinson 3y ago
    How typical to blame it on the devs instead of leadership.
    - siva7 3y ago
      I don't see where parent puts blame but let's not act like all devs are angels
- siva7 3y ago
  That’s a sign of ineffective product management and bad feedback culture. When the foundation lacks, agile can’t be done successfully. I’ve seen what you described a few times but also many times where it works as long as the foundation is good.
antisthenes 3y ago
> If you don’t finish the work you had planned to during a sprint then you fail the sprint, talk about why during the retro, then do a better job of allocating work in the next sprint. You don't even "fail" the sprint, that's a bad attitude. You just consider work spilled over and take on less work + spillover work next sprint. There's only cause for concern if you repeatedly have spillovers every sprint - that's usually mostly a manager issue, and sometimes IC's. Ideally you only have spillovers because of things that were not under your control - power outages, 3rd party vendor outages, etc.
- lionkor 3y ago
  Or you might have spillover because the team is very new and hasnt quite agreed on the value of a story point yet
  - zerbinxx 3y ago
    There are a lot of reasons for spillover in my experience. They’re all interrelated. First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. They may love the glory of leading or assisting a team of software engineers to build great products, but I’ve seen maybe 1 or 2 who are actually qualified to be the agile/process guy/gal. Additionally, they’re frequently counter-incentivized to be meeting jockeys, PowerPoint creators, and “culture people” who simply do not do the job as it’s meant to be done. As soon as ^^ happens, sprints are destined to fail, because the work of sizing tickets falls squarely onto engineers who would probably rather be writing code than talking about it, so they make informal agreements about value of a story point being a day’s work or not blocking tickets that don’t have defined success criteria, or what have you. As such, tickets are not properly vetted and grow to be massive, amorphous chunks of work that either allow devs to hide from the (painful/annoying) process of Scrum and just do their thing. The last (and worst) of the reasons spillover happens is that people are burnt out, unmotivated, or unrewarded by the process. If the “customer” (also a massive rats nest of a concept in Agile) isn’t at the demo and actively interested in the product being developed, any amount of “points” will feel arbitrary and useless. There’s no faster way to lose interest in Scrum than canceling a demo and having your developers lose faith that completing that ticket actually matters to someone.
xeromal 3y ago
I've been working since 2010 and every single company that drinks the agile coolaide has turned into a death march.
- Cthulhu_ 3y ago
  Same, but my experience isn't the same; in my experience it becomes boring because every sprint is the same, predictable, stable, little pressure, churn out one feature after the next. The companies may have drank the kool-aid but didn't let go of their existing management structures involving deadlines. And the developers / scrum masters / product owners / coaches did not protect their teams or processes.
  - xeromal 3y ago
    That sounds like heaven on earth. lol
atoav 3y ago
As someone who developes software I can tell you that I have seen those three work: A) if I am motivated, in the mood and it is my project I can program a thing in one go (e.g. if I have no dayjob, healthy breaks, time for sports, etc) B) One of my employers wanted software, while my dayjob was something else. I told them I can do it if I get a fixed day on which my other responsibilities don't need to be taken care of. After half a year the project was finished. The biggest delaying factor were external partners who used the "sprint" model. C) I do my current private project on two mornings in the week before work when I have time, it makes good progress. If you need to constantly crunch to finish things you are either bad at management or you have perpetual bad luck, one of which is more likely. Everything if done well takes a certain amount of time. And because things never go as planned and requirements change you can multiply that time by the value of pi. Additionally you should ensure that time is actually available for your employees and not something where they need to fulfill other crap (especially not your crap). If your employees are not totally incompetent (your responsibility again), you should be able to finish that project without a single hour overtime or any need to crunch at all. The problem starts when managers confuse how long they wish something would take with how long something actually takes. Often managers promise things go faster because they don't dare to break the illusions of their superiours (or gamble on the slim chance that they can whip their team into finishing faster to then reap the fruit of that success). Things take as long as they take. Multiply by arbitrary, pessimistic safety factors, you will finish it slow and steady on time, while still leaving space to try some things out.
michelangelo 3y ago
> They seem to be using “sprint” and “death march” interchangeably. That’s absolutely not what’s written there and I’m surprised the context - and the narrative goal of the article - is not being grasped. To put it more simply and distill it even more the gist is: “senior professionals know how to work and can manage their work structure/pace”.
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.
  - 3y ago
fulafel 3y ago
The word "sprint" has meanings outside of Scrum, I think it's used here in the dictionary meaning.
coldtea 3y ago
>They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. Sprints are just a way of breaking up work into discrete periods of time. That's already the same as saying "A, B, and C parts will be done in that period of time, then C, D, E, F" and so on. So you already pressupose what's to be done by when. And even if you roll-over tasks that haven't been completed to the next sprint, you still have this concept of falling behind (which is what "talking about why you failed the Sprint doing the retro" reinforces - and that invariably will lead to death marches and the fool's errand of "doing a better job of allocating work in the next sprint"). Whereas what they describe is "A (or B or C...) will be done when it is done, and the same holds for the whole project". So they work everyday 9-5, give it their best shot, and it is completed day by day, with no arbitrary deadline to have A, B, C parts completed by. If by using sprints you're going to do the exactly same thing (just work 9-5 everyday, and your project is ready when it's ready), then you don't need sprints. Sprints only make sense when you don't plan on doing that, but to use them as a yardstick of being on some schedule or falling behind, and as a way to force developers to work overtime to "keep up with the planning".
lamontcg 3y ago
> If you don’t finish the work you had planned to during a sprint then you fail the sprint that 'failure' bit right there is some bullshit that should get cut out.

psunavy03 3y ago

And this is why many agilists prefer to use the term "iteration," because "sprint" can be conveniently "misinterpreted" by toxic managers.

fredrikholm 3y ago
On that very note: https://www.youtube.com/shorts/liUiRfN9NzQ https://www.youtube.com/shorts/liUiRfN9NzQ

audiodude 3y ago

At every former company, where we tried to use Agile or sprints, we ended up reaching a system where we just had basically "one big rolling sprint". Every two weeks, only a few tasks were actually done, and every task got pulled into the next "sprint". Combine this with the fact that we weren't delivering any artifacts at the end of the sprint, so we didn't have any feedback from stakeholders and weren't really iterating either.

JimDabell 3y ago
> we ended up reaching a system where we just had basically "one big rolling sprint". But there’s no such thing as “one big rolling sprint” though. If it’s “one big rolling…” then it can’t be a sprint. It’s like dehydrated water. It’s conceptually incoherent. To untangle the wording of this, when you say your process became “one big rolling sprint”, what you’re actually saying is that you stopped using sprints, aren’t you?
- atoav 3y ago
  How can it be a sprint if nobody is running? /s
- zo1 3y ago
  Also known as the No True Scotsman argument https://en.m.wikipedia.org/wiki/No_true_Scotsman https://en.m.wikipedia.org/wiki/No_true_Scotsman. "You weren't doing real Agile™". The only reason I'm posting this is because we have had similar things happen in almost every attempt at using sprints. They're just not suited for any sort of formal/business context where you don't have absolute and frankly religious buy-in to the concept.
  - 261582335426158 3y ago
    It is a fallacy only if in support of "Trying to use sprints will improve your organization", it would not be a fallacy if in support of "The benefit of sprints are real but only if used properly" where properly is defined in some clear a priori way.
  - JimDabell 3y ago
    The “No true Scotsman” fallacy is when you introduce unrelated criteria to disqualify something that would ordinarily be a member of a group. It’s perfectly reasonable to point out that somebody who was not born in Scotland, does not have Scottish family, does not hold any kind of British citizenship, and has never even set foot in Scotland is not, in fact, a Scotsman. That’s not a fallacy. A sprint is a discrete period of time in which discrete software development tasks happen. A “rolling sprint” is conceptually void. You can’t have a discrete period of time that lasts indefinitely any more than you can have dehydrated water. The “rolling” part and the “sprint” part are mutually exclusive. I’m not even saying that they weren’t “doing real Agile” – I’m pointing out that what is being described has literally no meaning at all. You can’t be good or bad at it because it’s a meaningless term.
    - tacozilla 3y ago
      The purpose of language is to communicate, and audiodude did that quite effectively given the fact I chuckled when I read their comment, because I knew exactly what they meant. A "rolling sprint" might be an oxymoron, but it certainly isn't conceptually void. It quite literally does have meaning considering I and many others clearly understood the point he was making through his personal anecdote.
BaseballPhysics 3y ago
Sounds like you would've been better off with kanban. Did you ever consider switching?
- jimbob45 3y ago
  In my experience, the people choosing between Scrum and Kansan are not the ones participating in the Scrum/Kanban. Modern leadership attempts to take away as much agency as possible and wonders why everyone hates them.
  - js8 3y ago
    > Modern leadership attempts to take away as much agency as possible and wonders why everyone hates them. Not that I disagree, but I think it's not modern. In the past, it was probably simply much more accepted that the agency is taken away by authorities, that's just how life is. I think people grew much less tolerant of that recently (which honestly I think is a good development), and more willing to question authorities in general. The hate part then comes from nostalgia.
  - BaseballPhysics 3y ago
    First, that wasn't my question, nor was it you I was asking. But sure, let's go with this. Frankly, this reeks of empty cynicism and we can do better than that around here. Your experience is also far from universal. In my previous company I was part of the leadership core and not only did teams have agency to decide what process to use, we were actively encouraging teams to consider alternatives since our practices had become pretty frozen over time (old habits, etc). Maybe your problem is you just found yourself at shitty companies. The world is a big one out there.
YZF 3y ago
From my experience it can work. I've worked on a team where we got really good at estimating, had really useful planning sessions, a good backlog. Worked pretty well and had some advantages in terms of getting the team to be engaged and take ownership. The problem with Agile in general is that it can easily be twisted around to make anything you want. A great team doesn't need agile methods, but it can use them and still be great, and possibly even get some improvement with careful use. Agile intended to fix organizations but organizations don't want to be fixed, and certainly not by a bunch of software people...
ssss11 3y ago
In my experience I’ve found (1) some teams don’t embrace it, (2) some teams don’t break down large tasks or (3) it’s not suited to the work. Each of these result in your rolling sprint. I absolutely hate seeing buzzwords for the sake of them but often the work simply doesn’t work well with sprints.
Cthulhu_ 3y ago
That sounds like a lack of discipline and retrospection. This is also the problem I have with scrum; people don't stick to the process, and cite how the agile manifesto says that the process isn't important. But this is a misconception. Stick to the process (religiously) at first, then assess how it works. In this case: you did not meet your sprint goals, which either meant you overcommitted (meaning the next sprint you pick up less work), the tasks did not meet the definition of ready (that is, they could not be finished in a single sprint), or you had impediments that weren't solved on time. All of those need to be spoken out loud during a retrospective session, and action undertaken. Not having any artifacts isn't the issue, you still need to set a moment to stop your work, review what has been done, consider what went well and what could be better, learn and improve. If the learning is that scrum doesn't work for you - and you can show that you did it properly - then there's other processes that might work better for you, as suggested.
- lloydatkinson 3y ago
  How typical to blame it on the devs instead of leadership.
  - siva7 3y ago
    I don't see where parent puts blame but let's not act like all devs are angels
siva7 3y ago
That’s a sign of ineffective product management and bad feedback culture. When the foundation lacks, agile can’t be done successfully. I’ve seen what you described a few times but also many times where it works as long as the foundation is good.

antisthenes 3y ago

> If you don’t finish the work you had planned to during a sprint then you fail the sprint, talk about why during the retro, then do a better job of allocating work in the next sprint. You don't even "fail" the sprint, that's a bad attitude. You just consider work spilled over and take on less work + spillover work next sprint. There's only cause for concern if you repeatedly have spillovers every sprint - that's usually mostly a manager issue, and sometimes IC's. Ideally you only have spillovers because of things that were not under your control - power outages, 3rd party vendor outages, etc.

lionkor 3y ago
Or you might have spillover because the team is very new and hasnt quite agreed on the value of a story point yet
- zerbinxx 3y ago
  There are a lot of reasons for spillover in my experience. They’re all interrelated. First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. They may love the glory of leading or assisting a team of software engineers to build great products, but I’ve seen maybe 1 or 2 who are actually qualified to be the agile/process guy/gal. Additionally, they’re frequently counter-incentivized to be meeting jockeys, PowerPoint creators, and “culture people” who simply do not do the job as it’s meant to be done. As soon as ^^ happens, sprints are destined to fail, because the work of sizing tickets falls squarely onto engineers who would probably rather be writing code than talking about it, so they make informal agreements about value of a story point being a day’s work or not blocking tickets that don’t have defined success criteria, or what have you. As such, tickets are not properly vetted and grow to be massive, amorphous chunks of work that either allow devs to hide from the (painful/annoying) process of Scrum and just do their thing. The last (and worst) of the reasons spillover happens is that people are burnt out, unmotivated, or unrewarded by the process. If the “customer” (also a massive rats nest of a concept in Agile) isn’t at the demo and actively interested in the product being developed, any amount of “points” will feel arbitrary and useless. There’s no faster way to lose interest in Scrum than canceling a demo and having your developers lose faith that completing that ticket actually matters to someone.

xeromal 3y ago

I've been working since 2010 and every single company that drinks the agile coolaide has turned into a death march.

Cthulhu_ 3y ago
Same, but my experience isn't the same; in my experience it becomes boring because every sprint is the same, predictable, stable, little pressure, churn out one feature after the next. The companies may have drank the kool-aid but didn't let go of their existing management structures involving deadlines. And the developers / scrum masters / product owners / coaches did not protect their teams or processes.
- xeromal 3y ago
  That sounds like heaven on earth. lol

atoav 3y ago

As someone who developes software I can tell you that I have seen those three work: A) if I am motivated, in the mood and it is my project I can program a thing in one go (e.g. if I have no dayjob, healthy breaks, time for sports, etc) B) One of my employers wanted software, while my dayjob was something else. I told them I can do it if I get a fixed day on which my other responsibilities don't need to be taken care of. After half a year the project was finished. The biggest delaying factor were external partners who used the "sprint" model. C) I do my current private project on two mornings in the week before work when I have time, it makes good progress. If you need to constantly crunch to finish things you are either bad at management or you have perpetual bad luck, one of which is more likely. Everything if done well takes a certain amount of time. And because things never go as planned and requirements change you can multiply that time by the value of pi. Additionally you should ensure that time is actually available for your employees and not something where they need to fulfill other crap (especially not your crap). If your employees are not totally incompetent (your responsibility again), you should be able to finish that project without a single hour overtime or any need to crunch at all. The problem starts when managers confuse how long they wish something would take with how long something actually takes. Often managers promise things go faster because they don't dare to break the illusions of their superiours (or gamble on the slim chance that they can whip their team into finishing faster to then reap the fruit of that success). Things take as long as they take. Multiply by arbitrary, pessimistic safety factors, you will finish it slow and steady on time, while still leaving space to try some things out.

michelangelo 3y ago

> They seem to be using “sprint” and “death march” interchangeably. That’s absolutely not what’s written there and I’m surprised the context - and the narrative goal of the article - is not being grasped. To put it more simply and distill it even more the gist is: “senior professionals know how to work and can manage their work structure/pace”.

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.
- 3y ago

fulafel 3y ago

The word "sprint" has meanings outside of Scrum, I think it's used here in the dictionary meaning.

coldtea 3y ago

>They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. Sprints are just a way of breaking up work into discrete periods of time. That's already the same as saying "A, B, and C parts will be done in that period of time, then C, D, E, F" and so on. So you already pressupose what's to be done by when. And even if you roll-over tasks that haven't been completed to the next sprint, you still have this concept of falling behind (which is what "talking about why you failed the Sprint doing the retro" reinforces - and that invariably will lead to death marches and the fool's errand of "doing a better job of allocating work in the next sprint"). Whereas what they describe is "A (or B or C...) will be done when it is done, and the same holds for the whole project". So they work everyday 9-5, give it their best shot, and it is completed day by day, with no arbitrary deadline to have A, B, C parts completed by. If by using sprints you're going to do the exactly same thing (just work 9-5 everyday, and your project is ready when it's ready), then you don't need sprints. Sprints only make sense when you don't plan on doing that, but to use them as a yardstick of being on some schedule or falling behind, and as a way to force developers to work overtime to "keep up with the planning".

lamontcg 3y ago

> If you don’t finish the work you had planned to during a sprint then you fail the sprint that 'failure' bit right there is some bullshit that should get cut out.