9 Practices that Haunt Developers Working with Scrum
9 Practices that Haunt Developers Working with Scrum
Why Scrum has a bad name
This article was originally released in September 2022
Why Scrum has a bad name
Scrum promised to be liberating for developers. It should have been a radical shift from the command-and-control practices that defined many waterfall projects. Scrum is about self-managing teams and a sustainable pace. It should be an “ennobling experience” (Agile Software Development with Scrum (Schwaber and Beedle), 2001).
The world is flooded with Scrum Trainers, Agile Coaches, and Scrum Masters who spread the message of self-managing Scrum Teams that determine what they do and by when.
But the reality is very different for many Scrum teams and developers suffer from this. Many feel nothing has changed for the better. Some think Scrum is worse than Waterfall.
Here are 9 practices that haunt developers working with Scrum.
Crunch time every Sprint
Before Scrum took over the world of software development, organizations usually used traditional project management methodologies, often referred to as “Waterfall.”
Waterfall projects typically had detailed long-term plans and no feedback loops to inspect the product increments. Waterfall projects typically had a crunch time at the end of the journey. In the last weeks of the project, teams would often be pushed beyond their limits of sustainability to deliver according to plan.
Despite all the promises, many Scrum teams face crunch time far more often, almost every Sprint. Teams will end the Sprint with multiple days working overtime under high pressure to deliver “as promised”. This is a worse situation to be in than the occasional crunch time with traditional projects.
Scrum should not be about this. Teams should not worry about delivering according to plan every Sprint. They should focus on finding the best ways to achieve their goals. Not on delivering as promised. However, this is only the theory. The practice is that many teams suffer from crunch time.
Story Point Misuse
The majority of the (hundreds of ) Scrum teams I know use story points. At least half of them struggle with story points. The initial idea of story points was to move away from estimating in hours and make estimation easier. But this didn’t work out that way.
Story points are often misused. Especially because they are numbers and can be used for calculation. For example, the sum of the points of the items finished in the Sprint — called velocity — is typically considered to show the team’s capacity. And that opens a can of worms.
Firstly, the velocity of different teams can be compared and teams with lower velocity will have to defend themselves. Many outside of the Scrum sphere don’t understand that every team has its definition of what a ‘5’ is or a ‘13’ is. So you can’t compare the velocity of different teams.
Secondly, management often wishes to see a growth in the velocity. Velocity becomes the prime indicator of success, instead of whether the product increments bring the expected value. But also, teams will focus on efforts to do more every Sprint instead of focusing on “simplicity — the art of maximizing the amount of work not done” (Agile Manifesto principle). But teams could also inflate their story points. What used to be a ‘5’ will now be defined as an ‘8’.
There are many more examples of story point misuse. The bottom line of them is that instead of the product, story points become the centre of attention. An anti-pattern indeed, but oh so common.
Scrum doesn’t tell you how to estimate. If you don't want to estimate at all, Scrum allows for that too. But again, that’s theory only. Tell that to the managers who force teams to increase their velocity.
Cutting corners to “make” the Sprint
It saddens me that many teams I know think it is important to deliver as planned. This completely ignores the fact that Scrum is intended to be used in complex environments where you don’t know what will happen, even within the Sprint.
With the idea that they should deliver as promised, they sometimes feel inclined to cut corners. For example, on several occasions, teams have informed me they skipped the last part of testing to “make” the Sprint.
Scrum Teams should not focus on delivering all the items they planned to deliver. They should focus on setting a goal for the Sprint and find ways to optimize the chances to meet that goal.
Product Owner dictatorship
Another common issue is how Product Owners approach their team. I feel for the Developers who are put under pressure by the Product Owner who tells them what they should do and often also puts them under pressure to deliver.
Whether it has to do with the name of the accountability I don’t know (Product Owner), but contrary to what these people that pressure developers think, they aren’t higher in the hierarchy than the Developers.
Scrum teams should be self-managing. They should determine what they will do, how they will do it and by when. The Product Owner is one of the members of the Scrum team. Their specific responsibility is to manage the Product Backlog.
However the Developers should be in charge of what happens during the Sprint. They should be in charge of how much they can do in a Sprint and how they will achieve the Sprint Goal. This is not for the Product Owner at all.
Useless events
Scrum events can be extremely useless for developers. Examples are:
Daily Scrums that are mere status meetings, adding nothing useful;
Sprint Retrospectives are mere complaining sessions because the actual improvement issues are outside of the control of the team so nothing changes;
Sprint Reviews have no stakeholders present.
These are events that exist because “Scrum says so”. These types of meetings have a very negative impact on the developers:
they could have used the time to do something useful instead.
they are disrupted in their flow. It takes time to get back into the flow of your work when interrupted. So even a 15-minute daily eats away 30 minutes of the time of a developer.
meetings without any merit harm the cohesion of the team. Developers grow detached because everything the team does together (the events) harms them individually.
frustration mounts because the developers are forced to do things that bring them nothing.
All Scrum events have their purpose. In theory, that is. But this theory does not automatically turn into practice. Especially when the constraints for effective use of Scrum are missing.
External Dependencies
Scrum teams should strive to have a working increment of the product at least once every Sprint. This increment is input for the Sprint Review to inspect. I have seen and experienced all too often that teams simply aren’t able to do this due to external dependencies.
External dependencies happen when teams are depending on someone to do something that is outside of the team. This could be a database admin changing a table, a UX designer creating an update on the … UX, a security officer pushing an approval button, or a developer from another team who is the expert on a certain piece of code.
Few things are more frustrating than having an entire team stopped in its tracks as they wait for someone outside of the team with a different idea of priority.
Scrum teams are supposed to be cross-functional so they don't depend on people outside of the team. But how many teams are truly cross-functional in the sense that they don’t have these frustrating dependencies?
Release Trains
More and more Scrum teams work as a cog in the SAFe machine. They are part of a release train. Release trains magnify many of the issues I already touched upon. They introduce even more and longer meetings, even more dependencies, more fixation on velocity and story points, and even more focus on delivering what was promised.
At PI Planning, teams have to plan multiple Sprints ahead, taking into account the planning of the other teams. Despite the fact that their environment is complex and you don’t know what will happen.
The planning they created will haunt them every Sprint and the only way to make something out of it is to stick to the ideas they formed weeks and months before they discover how things actually work. But these insights may derail the train, so they are to be ignored.
Also, the sustainable pace is a pipe dream with all these dependencies and promises made.
Scrum should not be a part of SAFe. But the reality is different for many Scrum teams. SAFe effectively swallowed up Scrum and made it their own. It made an unrecognizable monster out of Scrum.
No Scrum mindset outside of the Scrum teams
One of the painful situations I have been in is being part of an Agile island. My team was one of the 18 Scrum teams that embraced agility and aimed to make the best of it. With the notion that complex environments call for different types of actions than traditional long-term detailed planning or command-and-control management.
We knew how important self-management and empiricism are. But our stakeholders and management didn’t and couldn’t care less. Every time we argued against detailed plans, or wanted to discuss our learnings with our stakeholders we were met with a lack of understanding and even contempt.
We were the dreamers who didn’t know how it worked in the “real world”. And they knew, according to them. Our attempts to embrace Scrum or any other agile approach were considered to be charming but naive.
Developers that are in this position are in a bad spot. They know things can be different but have no power to bring change. No, they are ignored and if they are lucky left to do their thing at their Scrum island. As long as they didn’t want even a minimum investment from people not on the island.
Delivery instead of discovery
Scrum is a discovery framework. It is intended to discover the best way to create value through delivering small pieces of a working product and inspecting that, learning from it. All of this is because Scrum is intended to be used in a complex environment where you don’t know what will happen.
But this notion has landed everywhere. Countless Scrum teams have their focus on delivery only. Teams are happy when they bring something to production as that is the success.
But the delivery of features alone is not a success. The real success comes when the feature actually delivers added value. for instance when people use it and are happy with it. Or when the feature improves the performance of a product.
Indirectly, the focus on features hurts developers. Because ignoring to learn if a product increment actually brings value will result in putting effort into things that turn out not to be useful at all or require more rework than would be required otherwise.
Developers suffer from the ineffectiveness of the team due to a lack of discovery.
Wrap up
Scrum is almost 30 years old and still, it brings so much suffering to the developers. While the examples I listed are all not the intention of Scrum or even in the spirit of Scrum, they happen nevertheless.
As a result, Scrum has a problem with its image of promising to be liberating for developers but being a prison instead.
I can imagine that developers are resentful when they hear they need to use Scrum. And if I could give one piece of advice to you when you are in this position: when you notice that the rest of the organization has no clue about agility and doesn’t want to move in that direction, stand up against using Scrum!
My team has to vote on how many points a story is worth in meetings. At our company, there is officially no definition of what a point constitutes, other than "more points takes longer than less points." I asked in one of these voting meetings, "Can 5 points mean 50 hours to me and 200 hours to someone else?" I was told "Yes". So we are voting for something that officially has no definition or meaning. We are supposed to come to agreement on something that is officially meaningless.