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
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.
Sprints Are Too Short for Specific Tasks
Deadlines can be stimulating, help you set priorities, and help you move closer to your goals every day. But it doesn’t work for every task. For things like design research, it doesn’t work at all. Designers need time to reflect on features and user experience across the application. This work does not fit into the scrum two-week sprints. They end up as a bottleneck for developers who need the design to be ready to estimate and start implementing stories.
In one of the companies that I worked with, we were a small team of a few employees. The CTO, who was also a kind of product owner and scrum manager, told me blatantly that my job is not to give feedback on the design. My job as a developer was to implement the feature as is. The trouble was that after I have implemented a feature, he would come up with a checklist of a dozen things that he didn’t like in the design, that I had to change in the code. Instead of spending more time in the design phase, researching and gathering feedback, this work was pushed on to developers. Without proper acceptance criteria defined, the story work could go on forever. “I don’t understand why this feature is not out yet,” he would often remark, “It’s not rocket science!”.
Design research is not the only task that doesn’t fit in the two-week sprint marathons. For software engineers to be creative and innovative, we need to have a playground to explore what’s out there and test things out. Under the constraints of a two-week sprint, it’s hard to come up with creative solutions. Often, we don’t have time to implement ideas properly, and the software quality takes a beating.
We’re Terrible at Estimating!
As developers, we’re terrible judges of how long things take to implement. In psychology, they call it the “planning fallacy”: A pervasive tendency to be overly optimistic and underestimate how long it will take to accomplish a task. It can be attributed to several factors.
First, we don’t consider our own past experiences while estimating. We never look back on the previous stories and think, “Oh, this looks similar to that other thing we did… We estimated that story a five, but it took us more time to implement.”
Second, we ignore the possibility that things won’t go as planned. We tend to estimate for the best-case scenarios, but what if things go wrong?
Lastly, what is this number we are estimating anyway? We never seem to agree on it. Are we estimating complexity, effort, or something else entirely?
This article by By Nikolay Sapunov does a great job of explaining how teams should estimate.
And to be fair, with time, we did become better at it. However, when a new person joined, or for projects that we started from scratch, our estimation was inaccurate again.
Looking back, most of the time we set unrealistic expectations for ourselves. When we failed to reach them, we were overwhelmed by guilt and self reprimand for the negative impact, not only on ourselves but also on the project. Receiving an email from the manager about how we should honor our commitment only made us feel worse.
Too Many Iterations Too Little Purpose
At the company I mentioned above, we were redesigning our front end application every couple of months. Only a couple of customers used the app we were building and before we gathered customer feedback the design requirements would change. We’d have to tear everything apart and start over. To me, this endless cycle of building the same thing over and over again was extremely demotivating.
My experience is not unique. Researchers have revealed that the positive emotions aroused by a job that we see as meaningful enable us to be smarter and more creative. For example, the Duke psychology professor Dan Ariely and colleagues conducted a study in which participants were paid to build Lego models, some of which were dismantled in front of them upon completion. People whose creations were preserved made, on average, 50% more Lego models than those whose models were destroyed, despite identical monetary incentives. As Dr. Ariely explains in this talk, we are more invested in a job when we have a purpose, even if it’s a small one.
Obsessing Over User-Value
User stories are great for focusing on features that bring value to the end-user. However, I find that product owners tend to focus too much on the end-user and the user-value and overlook everything else.
In my experience, code refactoring and infrastructure improvement were overlooked continuously in favor of user-value. Infrastructure related impediments piled up until they became overwhelming for the team. These were issues that everyone was aware of, yet, since we focused on always having a user value in every story, we didn’t have sufficient time to improve it appropriately.
One solution the product owner suggested was to include all the infrastructure work in the story and include this in the estimation. We tried this approach for a while, but we hit a wall. It blew up the story points and led to never-ending stories, which lowered the team’s satisfaction.
Scrum product owners must start considering infrastructure and internal toolings as products; with that, we need to reconsider who the “user” can be. Developers and employees who use internal tooling should also be considered as users of the story.
Daily Standups Are Useless
Daily standups become a status update for managers or scrum masters to find out who is behind schedule. As David Heinemeier Hansson says in his book Remote, “Constantly asking people what they’re working on prevents them from actually doing the work they’re describing.” Dailies are for developers to organize their work and report on roadblocks. Does everyone need to drop what they are doing and join it? No. We can do it async — people who are blocked can and should directly reach out.
Instead of blindly following the scrum approach, remember the first principle of agile: “ Individuals and interactions over processes and tools.” Ask yourself why you are doing things a certain way — what benefit is your team deriving from it?
The solution is something that works for your team and your specific requirements.
For my second job, I was lucky to work in an organization where a feedback culture was already established, which made it easier to bring up such topics and come up with something tailored to our needs. For us, this meant getting rid of the two-week deadline and the ceremonies that we deemed useless. We switched to kanban while keeping the parts that were working for us, such as the retros and the plannings.
