I don’t believe in sprints

And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what you wanted to have.

To avoid this scenario, it takes really dedicated project managers, product owners and lead developers, and not everyone has those...

> "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."

Next performance review, your manager goes: It seems like you're not really aware of a lot of techniques of how to solve problems efficiently. Maybe you should do more pairing with the other seemingly much better developers to strengthen your skills. And now you've cornered yourself as a junior for the next 2 years, who was "hired on the wrong level".

All of this is assuming that the team members will prioritise the performance of the team higher than their own performance, of which there are no incentives. The incentives is to make yourself look as good as possible (don't admit your idea is inferior), and skew the playing field to your advantage (insist on using the tools you know best) etc.

People simply don't spontaneously cooperate and simply don't "just get along" in a situation like this.

Even in hippie communities where everything is voluntary and there is no personal gain to be had, it still falls apart because some people just don't cooperate.

So how do you expect that to happen in a situation with money involved, and competition between people?

Why do the software industry and scrum think they have spontaneously discovered how people always just get along, inside a basic weekly planning schedule? That would literally be a nobel peace prize right there.

Yes, people like predictable.

Tell management every project will take a month, and meet that expectation, then management will be happy.

While someone else who takes the same work and says it’ll take one week then is consistently 2 days late will be viewed as less effective.

So, by squeezing people into a guaranteed timeframe, in a mini death march aka sprint, you are forcing people to make [very] conservative estimates.

For larger companies this might be preferred, but I would argue, smaller companies should try to move faster.

> I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.

Of the software I use (slack, cloud infra, vim, Jira) exactly none of them tell me precisely when a feature will be delivered. They work hard on it and release it when it's ready.

A deadline like "in a few weeks" is acceptable. A deadline like "in 17 days" is asking to be missed.

Oh my god! No, no, no, the author does not understand the purpose of sprints.

Assuming the originator of the concept of a sprint is Scrum (and it's a big assumption; normally I'd check, but I am lazy and somebody is clearly wrong on the internet), then the purposes of sprints are:

    - to set a regular cadence/rhythm to work, and to set up periodic checkpoints for inspection of the done product and adaptation of the work that follows
    - within a sprint, to produce a done increment that brings the team closer to the product
    - by the end of the sprint, to allow stakeholders to inspect the done increment, to observe if anything is being done wrong or in the wrong order, to collect the feedback, and adjust, if necessary, the plans against the reality
    - and then to repeat the same over the next iteration, and the next, and the next