Sprints: The Agile Industrial Complex Exposed
Over the past decade, I've engaged in many heated discussions about the feasibility of Scrum in software development. Typically, I have been silenced by the chorus of agile apologists. I decided to compile a list of my top 3 grievances regarding the framework (and agile methodologies in general), primarily to serve as a reminder to never subject myself to that shit again.
Daily Standups
The baseline assumption of a daily standup is that it's so useless that you have to keep it short and conducted while standing. Developers present what they delivered yesterday and what they plan on delivering next. Basically, you are expected to verbalize what a quick glance at the Done and In Progress columns on your JIRA board would have told you.
Usually, half of the participants don't pay much attention during the meeting, either because what's being discussed doesn't interest them (such as their colleagues' status updates) or because they simply have nothing to contribute to the topic.
Any information that could be useful to share is usually not allowed. For example, if you are struggling with a task and delve into the details of why, you are typically interrupted for wasting others' time. In reality, someone from the team might know how to tackle the issue at hand, and that "time wasted" would have been a valuable learning experience for the team.
If the team is working on different business areas that don't have much in common, they might begin to have several daily standups, one for each business area. And just like that, you now have multiple teams operating under the same umbrella team but with a common sprint goal.
Estimations
Relative estimates might seem reasonable at first. Instead of providing precise time estimates, you use a point system to categorize existing tasks and then compare new tasks with them. For example, if you employ a t-shirt sizing system, you could label a text change as XS and a change in the database table structure as M. When faced with the task of changing the background color of your homepage, you assess it in relation to other items.
However, relative estimations are essentially a facade. Behind the scenes, the relative sizes are initially converted into numerical values, which are further translated into time. For instance, T-shirt sizes like XS, S, and M might be equated to 1, 2, and 3, respectively. These points are then used to calculate the entire team's velocity, indicating how many points they can complete in a sprint.
Eventually, a manager begins to wonder how many XS tasks are equal to an M. Since XS = 1 and M = 3, it seems reasonable to assume three. Now you are in a situation where three 15-minute text changes are equivalent to altering a database schema and migrating data.
What's often overlooked in estimates is their subjectivity. Making estimates at a team level relies on the assumption that everyone is equipped with the same skillset and domain knowledge. In reality, a team might include a progressively balding, tenured Java Bull, a blue-haired JavaScript Elitist fresh out of college, and everyone in between. The Java Bull will have much harder time changing the background color of the homepage compared to the JavaScript Elitist. Strangely, this fact is frequently ignored in estimates. When the team cannot reach a consensus on whether a task is an XS or M, they often compromise and label it as S. This is one of the most perplexing practices I have personally witnessed.
Sprints
Does your team have a fixed release schedule? Are you repeatedly working on similar tasks, or do you tackle different challenges in each sprint? If you are not an assembly line, why do you insist on having a predefined scope (the sprint) that the team commits to?
If you are building software used by actual users, you will rarely have weeks of uninterrupted development time. For instance, if someone takes down your database by using an emoji in a comment, you will likely address that situation before attempting to change the background color of your homepage. When Hildebrand eats expired yogurt for lunch and spends the next 48 hours in the shitter, your two-week master plan also goes down the drain.
Why subject yourself to the agony of trying to estimate the unknown, planning for weeks in advance, only to face repeated failures? Why create incentives for tasks to be overestimated just to free up time for other activities? Why delay a bug fix by weeks simply because "it's not in the sprint"?
In closing
The core concept of Scrum centers around sprints. Once you stop doing sprints, you'll realize how little value the entire process, with its alienating terminology and rituals, brought. There's no longer a need to estimate every item on your list, have daily meetings to ensure you're on track to meet your sprint goal, or wait until the end of the sprint to demo and deploy software. Awkward retrospectives, where you often try to come up with innovative excuses for failing to clear your sprint backlog, become a thing of the past.
Just stop with the nonsense.
I’ll never yield to the Agile Industrial Complex. This is a hill I am willing to die on.