Written by Paul Cowan ✏️

Many of us have gone to the gym and, initially, obtained good results. Once your body has adapted, the same routine may help you maintain, but you won't see any further gains and you might even start going backward.

I feel scrum as a methodology for delivering software projects is suffering from the same problem. The scrum cycle, or the way of practicing scrum, is either taken too literally or adhered to too rigidly.

What is the purpose of scrum?

Scrum should be about defining an achievable sprint goal for two weeks. Scrum should encourage teams to learn through experience, self-organize while working on a problem, and reflect on their wins and losses to improve continuously.

In my experience, scrum has, unfortunately, ended up destroying the central tenet of agile, which is people over process. A lot of this comes down to bad management and the rise of the certified scrum master.

Standups are for managers

The daily scrum is supposed to be a 15-minute, time-boxed event for the development team to plan for the next 24 hours. Unfortunately, standups have become a medium to fixate on JIRA tickets moving across the board.

Moving tickets across a set of swim lanes is a bit like counting lines of code as a metric of success. A developer can appear productive simply because of how quickly they have moved their tickets. On the flip side, a focus on the board can reduce good developers working on challenging problems to look average.

Self-organizing teams

If done well, scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to improve continuously.

In scrums advocated by the infamous scrum master, you need to clear tickets, Moreover, there is no actual check on the quality of the work, which is often determined by a nontechnical project owner. That incentivizes going into a void and focusing on outputting code.

Mythical story points are not mythical

Story points are units of measurement for expressing an estimate of the overall effort required to fully implement a product backlog item. Or, at least, they should be.

In my experience, story points can encourage teams to game the system. After falling short of meeting their targets in several sprints, savvy project managers will become fearful of bringing too much into a sprint.

The fear of failure leads to small story sprints where only minor ticket items are brought into play to ensure their completion. The bigger picture becomes irrelevant, and focusing on small things will eventually take the project off the rails.

I have seen this firsthand on a project where each story had to have an automation test. These tests come with a high maintenance budget, and the automation tests for this project slowed development to an almost standstill. When automation testing becomes the focus, fitting the development and maintenance processes into a two-week window escalated the continuous integration build time to two hours. The pipeline ground to a halt and change was forced.

The converse of bringing too little into the sprint is carrying too much into the sprint. Developers and testers cut corners while accruing technical debt. The debt is never repaid, and the spinning plates will eventually crash to the ground, causing a massive and expensive rethink.

Instead of relying on story points, we should track work completed and not what we estimated. I find this staggering. If I want to know how long a similar piece of work took, I want to know the actual time and not the estimate. If all your stories are small enough, then you don't need estimates.

Retrospectives are boring

The purpose of the retrospective is just that: to reflect. We look at what worked, what didn't work, and what kinds of experiments we want to try.

Unfortunately, what it boils down to is putting the same Post-its of "good teamwork" and "too many meetings" in the same swim lanes as "what went well," "what went wrong," and "what we will do better."

After the first retro, it is boring. The certified SCRUM master's lack of imagination is a massive part of this, but I feel the retro is now a tired and dull waste of time.

Hackathons and practical activities might serve better than a retro for trying out new paradigms. Collaboration is implicit in a hackathon, and the only way to succeed is with good teamwork. Working on a fun problem with an imposed deadline ensures learning.

Retros force people into a room twice weekly with a "let's be retrospective now" mindset. It becomes repetitive and boring, and there is no dynamism. Teams need new stimuli, not the same redundant two-week groundhog sprints.

Let's retro scrum

Scrum is often the enemy of productivity, and it makes even less sense in the remote, post-COVID world.

The premise of scrum should not be that one cookie cutter fits every development team on the planet. A lot of teams are just doing things by rote and with zero evidence of their effectiveness. An ever-recurring nightmare of standups, sprint grooming, sprint planning and retros can only lead to staleness. Scrum does not promote new and fresh ways of working; instead, it champions repetition.

Let good development teams self-organize to their context. Track what gets shipped to production, add the time it took (in days!) after the fact, and track that. Focus on reality and not some vaguely intelligible burndown chart. Automate all you can and have an ultra-smooth pipeline. Eradicate all waste.

Constantly re-estimate as you know more. The idea that you are estimating and sticking to your mythical story points when you know the least at the start of the work does not hold much water.

Adults playing planning poker is as ridiculous as it sounds. ♣️ ♦️

LogRocket: Debug JavaScript errors easier by understanding the context

Debugging code is always a tedious task. But the more you understand your errors the easier it is to fix them.

LogRocket allows you to understand these errors in new and unique ways. Our frontend monitoring solution tracks user engagement with your JavaScript frontends to give you the ability to find out exactly what the user did that led to an error.

LogRocket records console logs, page load times, stacktraces, slow network requests/responses with headers + bodies, browser metadata, and custom logs. Understanding the impact of your JavaScript code will never be easier!

Try it for free.