Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress. A good manager facilitates these items. A bad manager just throws tickets on a Kanban board.
Sure, if you have a team that can do all the above without sprints, that's great. But I bet they have some other method or social structure that makes team management effective. Most software teams do not have that without some type of formalized structure, especially when new devs rotate into the team.
So, I say stop criticizing the concept of a sprint and start holding your manager accountable for proper communication, effective knowledge sharing and realistic issue tracking. You wouldn't accept crap code, don't accept crap management. Do this and your sprints will add value (and the meeting will be shorter too!).
> Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress.
The real problem, of course, is the word "sprint", which (whether you like it or not) implies something.
A sprint, be definition, is unsustainable.
It's Pythonic levels of hilarity that we adopted this word to describe software development. It's Shakepearean in the tragedy that so many defend it.
Choose another word, like, "jog", "amble" or similar, and you won't see the same level of backlash against it.
I'm with you about holding management accountable and avoiding crap management, but I think it is orthogonal to sprints. Sprints might be a solution for some teams, but I have seen them fail far more than succeed. Actually ... I've never seen them succeed.
I've seen them succeed. I think the differentiating factors were 1. everyone worked on lots of different bits of the code; there weren't bits that were "owned" by someone, and 2. the end goal was pretty obvious.
10 years into my career I'm still waiting for this mythical "good manager". It's almost as if there's some intrinsic opposition between workers and employers, hmm...
There was some research that when MBAs were hired as managers for dev teams instead of other devs, dev compensation fell. Managers and devs play a different game.
Sure, if you have a team that can do all the above without sprints, that's great. But I bet they have some other method or social structure that makes team management effective. Most software teams do not have that without some type of formalized structure, especially when new devs rotate into the team.
So, I say stop criticizing the concept of a sprint and start holding your manager accountable for proper communication, effective knowledge sharing and realistic issue tracking. You wouldn't accept crap code, don't accept crap management. Do this and your sprints will add value (and the meeting will be shorter too!).