Not a single workday goes by without hearing people praising the virtues of Agile. For many, Agile became synonymous with Scrum. In this article, I argue that Scrum is very hostile to developers. More generally, I will explain why Scrum is not designed for humans.
I'm not planning on explaining what Scrum is. There are numerous resources that could do that better. The Scrum guide is a good place to start. In a nutshell, Scrum is a framework for product development with its sets of roles, artefacts and ceremonies. No, I’m not talking about a cult or a secret society. I’m talking about something that has become at the core of many people's work life.
Scrum is anti-developer
In his book Developer Hegemony, Erik Dietrich makes a very interesting observation. He notes that developers are a hot commodity nowadays. Companies are willing to shell high salaries and incentive packages to recruit the best talent. However, once those developers join a company, they are faced with impediments that stop them from reaching their true potential. Mountains of bureaucracy, layers of management and interfering with their daily work are just a few examples of that. Dietrich imagines a future where developers flip the table and take back control. We are not talking communist revolution and seizing the means of production. We are talking about being in charge of their destiny and actually delivering their full potential.
Scrum is yet another red tape thrown at developers. Instead of allowing developers to self-organise, someone high in their lofty tower decides how the team should be working. Funny enough, the Agile bug seems to only infect developers. The remaining parts of the organisation are unfazed. The same people forcing Scrum down developer’s throats would not be even there if the organisation were truly agile.
I dislike Scrum because it makes a few wrong assumptions. First, that developers are lazy and need to be micromanaged to deliver. While many developers can be underperforming, putting them under the spotlight will only make the problem worse. Second, that the process of software creation is indistinguishable from any industrial manufacturing process. Claiming that uncertainty and unpredictability are not inherent parts of software engineering is as good as relying on the planets' positions to determine one’s destiny.
It is true that not all developers are exemplary employees, but more often than not they want to give their best and be proud about the products they deliver. When things go wrong in the development team, people are quick to jump to the conclusion that developers have to be micromanaged to extract every ounce of productivity from them. However, the problem is often somewhere else in the chain.
A game of poker
Scrum advocates estimation as a way of managing the team's workload. At first glance, that seems to be a very developer-friendly measure. Who wouldn't want to achieve a constant pace of delivery that keeps the users happy and saves the development team from burndown? In practice, estimations end up being yet another pressure mechanism.
Humans work in different ways, at different speeds and at different times. The myth of a constant pace of delivery does not reflect the reality of working in software development. Developers have good days and bad days. They exist outside the realm of their roles at work. They get sick, go on holidays, lose motivation etc.
Uncertainty and unpredictability are hallmarks of software creation. That by itself is enough to invalidate the need for estimations. Pushing them on a team is a game of dishonesty and lack of trust. Everybody involved knows that those numbers carry little value. The time wasted making predictions and false promises should be used to bring real value to users instead.
Developers are not stupid. When they can't change the system, they start to game it. They will use estimations to advance their own agenda. They will overestimate and deliver less. They will underestimate to make sure something they feel passionate about is picked up for development.
What do you stand for?
The Scrum guide defines the daily stand-up as a short meeting for the development team to discuss their progress and impediments. In theory, I see some value in that. However, it makes the misinformed assumption that a team needs a specific ceremony to talk. In practice, teammates should and do exchange ideas all the time.
What happens more often than not is the liberal reinterpretation of the daily stand-up. Managers and product owners attend and turn this ceremony into a status update meeting. Developers are forced encouraged to share the teeny tiny details of their work with people who probably have little knowledge of and no interest in what is being said.
Worse still, many companies use the daily stand-up as a sneaky way to get everyone in the office by a certain hour. This hinders any prospects for flexible working hours or remote work. Attending the daily stand-up becomes the number one reason why people show up at work, not the work itself.
Build it and they'll come
Scrum is a great masquerade for agility. True agility requires no ceremonies and no artefacts. True agility is a cross-organisation mindset that doesn’t apply to the development team only.
By adopting Scrum and following its guide, either to the letter or not, people believe they will magically become agile. The belief is that a time-delimited sprint ensures the ability to change course. That having retrospective meetings will enable the team to iron out issues in their process. That estimating and measuring the team’s velocity will make people more productive. In reality, none of that is true.
Scrum has become a perfect example of cargo cult agile. Everyone is waiting for the benefits to come raining down. In reality, the sky is blue with no clouds in sight, even though the team has been doing its rain dance for weeks.
Scrum often hides the fact that true impediments are not in the development team itself, but further up in the hierarchy. The “follow the Scrum guide” commandment is a great mirror and smoke show for denying true change elsewhere in the organisation. The narrative is often flipped to suggest that the team problems stem from not applying Scrum strictly enough, for being too lenient in estimations and too ineffective in their retrospective. They are encouraged to dive deeper into Scrum while the rest of the organisation remains unchanged.
Going clear
Some teams can and will use Scrum. A prepackaged workflow could work under certain circumstances, but it achieves nothing in terms of agility. Agility is the antithesis of process and ceremonies. Agility is giving a development team trust to self-organise. Agility transcends all layers of an organisation. In fact, a truly agile organisation does away with most of its layers.
Be careful anytime you buy into a methodology with inflated claims, rigid rules and unintuitive workflows. An ecosystem backed by certifications and “coaches” will create a feedback loop that perpetuates its shortcomings and hinders true progress.
Any team can and should decide its own workflow. Processes are discovered, adopted and improved along the way. If you are a developer, make sure you are part of that conversation. By deferring those decisions to the “wise” men and women of the organisation, you give up the agency to determine your own fate. Any process in place should be there to serve you and not the other way around.