Scrum Isn’t That Great

After a colleague had a burnout on the day of the cycle review, I realized how stressful sprint commitments could be

Photo by NESA by Makers on Unsplash

A few years back, on a Wednesday afternoon — the day of the cycle (or sprint) review — my team was struggling to merge a PR and meet the release deadline. We’d already carried on that story from the previous sprint, so dragging it over again was not an option. There were so many comments on the PR, and though we skipped lunch to work on it, it was nowhere near ready. As the deadline loomed, my colleague lost his shit, cursed everyone, packed his laptop, and stormed off.

Something switched for me that day. These sprint deadlines and the false sense of urgency created around them put too much stress on our team. In each cycle review, which were attended by everyone in the company, the scrum master showed graphs of how many stories of the ones we committed were finished, and which teams failed to hold their commitment.

What struck me about this is that only the engineers’ work was scrutinized this much. Other people in the company were rarely closely monitored. It made me wonder. Why aren’t engineers trusted to manage their work and time? Why is everyone so obsessed with optimizing our productivity? What if Scrum is just a cover-up for micro-management?

In this piece, I want to address a few things that I believe are wrong with scrum. I know that some of you will say the problem is not scrum itself, it’s how it’s implemented, or maybe they’ll blame the company culture. To those, I say — if it’s that great, it shouldn’t be so hard to implement.