The Daily Scrum
Does it HAVE to be Daily?
If I had to pick the one thing I hate most about Scrum, it would be the Daily Scrum. More than anything else, it makes me want to call in sick or schedule a last-minute root canal. Anything to escape!
I always feel pressure to prove I actually worked:
“Oh geez, let's see. After breakfast, I remember I did some code reviews. Then it was lunch time… yeah, but they were big code reviews. Oh and I spent some time helping Dan! He couldn't get VSCode to compile the project for some reason. Anyway, after lunch...”
It's hell.
Daily check-ins, for professionals, for adults in general, heck even for children, are micromanagement. If you have even a modicum of trust in your coworkers, you'll give them more time to make progress — especially in software development, where any number of things can go wrong, where fixing a broken environment can take more than a day, where it's not uncommon to need a book or an online course to figure something out, where you can waste all afternoon hunting down a missing semicolon.
Engineering work is not linear, and you can easily go several days without making any progress worth mentioning. And that should be okay! But with Scrum, “the beatings will continue (daily) until morale improves.”
I'm tired of feeling ashamed every morning, because those who don't write software (and, inexplicably, some who do) are going to think I just watch YouTube videos all day. It makes me angry and depressed. And then, all I want to do is watch YouTube videos all day. It's a vicious cycle.
I know team-Scrum is going to say, "It's just a check-in, and the guide says you can do it however you want. Sounds like a bad implementation to me. Scrum's not to blame." (That gives me a great idea for a t-shirt: "Scrum doesn't hurt people, I do." What do you think?)
But that's where they get it wrong. Merely requiring a daily meeting is a statement about how often developers need to account for themselves. Even if co-workers and management are the most benevolent people in the world, just knowing that someone could ask for my status and worrying that I won't have a good answer is enough to do plenty of damage.
Besides, if you have to get together every morning at work, what else are you going to do except ask each other how the work is going? It's just going to happen, like uncomfortable small talk at a party where you don't know anyone, "So, what do you do for work — like yesterday for example?"
And sadly, people are petty sometimes, especially if they had a day with more obvious progress, and are all too happy to judge someone who maybe got stuck. Scrum gives them a chance to be petty way too often — and gives stuck programmers way too little time to get to a place where they can demonstrate more progress.
And if you need any more proof, look at how well the Scrum Masters of the world have gotten the message. Virtually all of them treat Daily Scrums as status meetings. They ask, "What did you do yesterday? What will you do today? Any blockers?" (Which they were taught to do in official Scrum certificate training. I know. I've been there).
They don't do this because they misunderstand Scrum. They do it because the Scrum Guide calls for daily check-ins, and that alone telegraphs the message: developers need to be watched closely. Otherwise the manual would say,"Developers alone can choose when and how they coordinate their work — because they are adults."
Scrum is not for you; it is for management. Software developers will continue to be exploited by management. It's an exploitation framework, not an engineering framework. I know it's easy for me to say, but save up and go independent, or look for a lower salary job that doesn't have such nuisance.
The Daily Scrum is not intended to be, nor defined as, a check-in. The Scrum Guide describes it as “for the Developers”, who can “select whatever structure and techniques they want”, and the PO and SM are actively involved only if they are actively working on items in the Sprint.
Think of it as the developers just huddling to ask “what’s the latest and any problems we need to deal with to meet our sprint goal?”
I acknowledge that it is taught, coached, and practiced horribly by the majority. Having seen and been a part of well performing Scrum teams, I hate to see people miss out on the opportunity it provides due to others’ misapplication.