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!
Top comments (1)
I feel like this post is more of a rant about how scrum is not working for you, instead of why scrum in general is 'irrelevant'.
Scrum is extremely powerfull to give a team focus on deliverables and growth, but you have to make your own adjustments in order to:
If your retrospectives are boring, because everyone keeps bringing up the same good stuff, you might have to shorten or spice up your retrospective some other way. Same goes with quality. Scrum doesn't define that you need to do quality checks, that something you should do in your own development process.
Finally, I think the entire scrum methodology doesn't always work for any organisation. You should pick out the bits and pieces that work for your organisation/team and provide value. A good example of this are story points. In my organisation, working with story points is a hassle, since our customers expect a rough estimate in hours. What did we do? Don't estimate in story points, but in hours.