Scrum isn’t perfect. There are things to dislike about Scrum. I have been critical about it as well. But what strikes me is that most critics bash Scrum for reasons that aren’t about Scrum. These things are attached to Scrum giving Scrum an undeserved bad rep.
You could argue that when so many people voice these issues, Scrum IS to blame. I think there’s some truth in that. It seems the creators of Scrum weren’t vocal enough to clarify these misunderstandings. But at the same time, is it so difficult to study Scrum? The Scrum Guide is only 17 pages. It contains Scrum in its entirety.
Today, I have listed 5 things that have given Scrum an undeserved bad rep. Do you agree? Do you have other things to add? Let me know in the comments!
1. Micromanagement
Scrum can (but should not) be used to micromanage the team. In these situations, teams need to work at a predetermined capacity (often called velocity) to maximize the delivery of the items from the backlog. Product Owners, Scrum Masters and/or managers bully the Developers into taking more than they can chew.
The worst thing is that the Developers know this means working overtime or cutting corners in quality. Every Sprint is a deadmarch and the pressure is mounting. The last day of the Sprint doesn’t mean relief, because the new Sprint starts immediately.
I recognize this situation and I know many teams are in this situation. However, this has nothing to do with Scrum. Here are some points from the Scrum Guide to make this clear:
Scrum Teams internally decide who does what, when, and how;
Scrum knows no hierarchies;
The Developers determine how much work they can do;
The Developers own the Sprint Backlog, which includes the plan for the Sprint;
The commitment to a Sprint is achieving the Sprint Goal. Developers do NOT commit to finishing all items as originally planned. The Developers may change the plan to maximize the chances of reaching the Sprint Goal;
Developers need to adhere to a Definition of Done, which they partly define themselves. These are quality standards to prevent Developers from skipping things, like testing or code reviews.
Developers work at a sustainable pace. They can’t be pushed beyond their limits to ‘make’ the Sprint.
2. Sprints are mini waterfalls
Another often-cited complaint is that Sprints are waterfalls with strict deadlines. A larger project is cut into smaller Sprint-sized pieces and teams are expected to deliver the project piece by piece. The most problematic issue is that teams now have crunch time frequently (at the end of the Sprint) instead of at the end in a standard waterfall approach.
There are many things wrong with this. Firstly, Scrum is a framework for addressing complexity. “In complex environments, what will happen is unknown” - Scrum Guide 2020. This is why Scrum works with the Product Goal to formulate the desired future state of a product. Scrum acknowledges that teams may not know how to reach this goal, but they will find it while working in Sprints. Sprints have Sprint Goals, which are stepping stones towards the longer-term Product Goal.
Product Goals and Sprint Goals help to define the desired outcome and leave room for the team to find the best way to reach this outcome, addressing complexity through empiricism. They also help the team to collaborate to reach their goals.
3. Excessive Meetings
Many Scrum haters think the events (or meetings) are the worst. They are time-consuming and soul-sucking. They don’t see why the Sprint Planning needs to be hours long when you can decide to select the items from the top of the ordered Product Backlog within 15 minutes. They hate the Daily Scrum as it’s no more than a status update to micromanage the progress. They wonder why the Sprint Review is needed because you can demo your product whenever you wish to. They don’t see the use of a Sprint Retrospective as they are discussing the same issues every time.
The idea that Scrum has too many meetings often originates from the idea that Scrum is a delivery framework. Teams plan to deliver a selection of items at the start and then work towards finishing these items by the end of the Sprint.
But this is not what Scrum is intended for. Sprints exist to achieve a goal within the coming week, two weeks, months or even days while not exactly knowing what the team needs to do. A Sprint is about managing complexity by learning what makes your product valuable by creating Increments, verifying these Increments and then learning from that to understand what to work on in the next Sprint.
The Sprint Planning exists to define the Sprint Goal and create a plan to achieve this goal. The Daily Scrum is to verify the team’s progress towards the Sprint Goal and adjust the plan to course-correct if needed. The Sprint Review is the moment to reflect with the stakeholders if the latest product Increment helps to maximize the product's value and achieve the longer term Product Goal. The Sprint Retrospective is not a complaining session, but it is the moment for the team to take charge and change their way of working to be more effective.
The Scrum events help to foster empiricism. They should not be used to micromanage the progress of the team. On top of that, the Scrum events should replace existing meetings. They should not be on top of other meetings.
4. Story Points estimation gives a false sense of security
Story points: love them or hate them, it seems. Those opposing story point estimations argue that they give a false sense of security and are often incorrect. Some even argue there’s no correlation between story point estimates and the actual duration of completing a story.
I like working with story points. Although not to accurately predict the complexity of an item. My main purpose is to do story point estimating (planning poker) with the team to get a mutual understanding of everything the teams need to do to complete an item. I value the alignment more than the resulting number from the exercise.
The story points are estimates only. When you acknowledge your work is complex (and you don’t know upfront what it exactly entails), you also should acknowledge the actual amount of work will differ from the estimation. This is why I recommend teams not to plan to their full capacity, but to 50% to 70% of what they typically should be able to finish. Teams should have room to creatively explore their way to reaching their goals.
When we take away the aspects of estimates to being promises and teams planning to their full capacity, story points can be a helpful instrument to align the expected work to be done.
And oh, did I forget to say that story point estimating is not Scrum? Also: Scrum doesn’t mention estimation (anymore).
5. We can’t work in two weeks Sprints
Somehow, people believe Scrum requires working in 2-week Sprints. Many Scrum Teams started working in 2-week Sprints because they thought this was the norm. Unsurprisingly, this does not work for everyone. Some teams may easily be finished well before the end of the 2nd week. Other teams may struggle to reach their Sprint Goal every time. The fact that teams think they must use 2-week Sprints is a factor in despising Scrum.
But Scrum doesn’t say this. There’s a maximum length for a Sprint (one month). There’s no minimum length. In theory, teams could work in 1-day Sprints. So, if teams believe a different length works better for them, I recommend shifting to this.
What are your examples?
Do you agree with me? Or do you have other examples that you believe are more problematic? Please share them in the comments!
The most frequent bad practices I see in many Scrum implementation, even from Scrum Master and others Agile Coaches:
1. Scrum replaces technical expertise and good software engineering practices, like design, architecture, continuous delivery, TDD, documentation. On the contrary, Scrum absolutely required them.
2. The Scrum values and things like Product Goals and Sprint Goals are optional, or not SMART.
3. The goal of the team is to finish the Sprint Backlog, and at the end of the sprint, the unfinished stories are put at the start of next sprint.
4. The sprint demo is a recording with a lengthy explanation of what the team have worked on during the sprint, with no actual increment.
I put the above because of all them often leads to what you cited above:
- needs more meetings because there is no real feedbacks during the review
- crunch time because instead of a goal, the team has a list of tasks
- fight between stakeholders and the team because the value aren't implemented between them.
- micromanagement because the team has give up on best practice or continue to use waterfall practices instead of empirical ones.
Keeping the team away from the business context and making the relevant product decisions outside the Scrum Team... Scrum then becomes a manangement tool with heavy overhead.