[noodle]

Modern corporate Agile isn't the same as Agile Manifesto Agile. Even though they have basically the same name, don't mix the two up.

Sprints are one tool in your toolbox. Use them when it makes sense to do so.

I view them as most helpful around scope limiting. The goal is working software of some sort by the end of the sprint. That requires you to think about the problem at hand and how to break it apart such that you can achieve that goal inside the sprint. Some work doesn't require this boundary. Some work does.

[freedomben]

> Sprints are one tool in your toolbox. Use them when it makes sense to do so.

This sounds great in theory and I would totally agree (in theory), but my experience has been that it's the PMs or executives or higher managers that make the decision, regardless of what the engineers think. In fact, most of the times I've seen sprints pushed back on it ended up in bad feelings and unintended offense taken by PMs. In the end nothing chnages, except that the engineer who "stirred the pot" loses favor in the eyes of management.

If it was up to each developer or developer team, I would agree, but in reality it rarely is.

[noodle]

Those types of conversations are going to depend a lot on their context.

Like, if your company is a large company that has a lot of operationalized tooling around corporate agile, one team saying "hey lets not do this" is not going to go over super well. A smaller company with fewer and/or more autonomous by culture teams will have more success.

But it will also depend on what kind of way its communicated. Can't just say "lets stop doing sprints", you have to make sure you're justifying it and/or offering alternatives that speak to the needs of the other members of your team/company.