If not, why not?
I’ve worked in companies where sprints worked fine and others where they became a source of frustration (largely I think due to overly ambitious sprint planning).
Disclosure - I’m one of the founders of a company making a new issue tracker [0] and how best to support teams that work in sprints/cycles is something we care quite a lot about
0: https://Kitemaker.co
We don't get much value from them because there is little sprint planning, and 2 days before the review there is a push to figure out what is "done" to present.
I have worked on other teams that embraced the planning aspect better and it was a source of reassurance that everyone was on the same page.
The primary value (when I was on a team that did it "right") was the common context that was shared by all and represented in the kanban (literally, sticky notes on the wall and some masking tape). There was transparency and traceability. I'm not sure it made us more "efficiency" or "productive", but i removed a lot of frustration of being in the dark about what the team is doing.
That makes a lot of sense. Do you think you could have achieved the same thing with regular sync ups or prioritization meetings or discussions without worrying too much about what you'd get done the next X weeks?
> without worrying too much about what you'd get done the next X weeks
We didn't worry too much about metrics or progress. We just had everything going on in sticky notes on the wall. You could walk in, look at the wall and get an idea of what's going on outside of what you are working on.
Personally, I like whiteboards and sticky notes(gives you an excuse to get up and move around). But it can be jira, trac, a wiki, a textfile in the repo.
I like knowing what's going on around me and how things fit together. Others like working in isolation and following requirements. In my experience, understanding the origin of requirements and the context is important to the dev process.
But sprints does not necessarily equals cycles, and cycles does not necessarily equals Scrum or Agile.
I totally agree with you stand that "overly ambitious sprint planning" is the root of all evil, many teams forget that planning is not a construction plan but more of a show of intents and you can see the stress level fluctuating between the start and end of sprints.
Another big problem is task estimation, we know that we are bad at it but the "process" forces us to estimate anyway. This in turn leads to more of the above mentioned stress since we usually under estimate.
I found that many times usually Kanban, or ScrumBan works quite well and mitigate some of the mentioned problems.
It's frustrating due to overambitious programs and management 'metricizing' it.