My current employer promotes scrum/agile, so we have sprints with company-wide sprint reviews.

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.

> There was transparency and traceability

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?

I think it's possible, as long as there is a central place with all this information.

> 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.

I don't even remember when I last worked in a non sprints/cycles way (the year started with 201x or even 200x).

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.

We use sprints.

It's frustrating due to overambitious programs and management 'metricizing' it.