Some things are easier said than done. Take scrum, for example. It’s relatively easy to grasp Scrum principles and practices But we all know that mastering the day-to-day implementation can be extremely challenging. You can’t change deeply ingrained habits overnight, after all.
However, you can only achieve an Agile mindset and way of working if you identify and eradicate negative habits, known as anti-patterns.
In this article, we’ll cover a comprehensive list of scrum anti-patterns and what you can do to fix them.
Table of Contents
- What Are Scrum Anti-Patterns?
- Code Review Anti-Patterns
- Developer Productivity Anti-Patterns
- Issue Tracking Anti-Patterns
- Sprint Planning Anti-Patterns
- Team Health and Culture Anti-Patterns
- Fixing Scrum Anti-Patterns
What Are Scrum Anti-Patterns?
An anti-pattern is simply an approach that seems like a good idea, but likely won’t work out very well in the long run. How many of you can say you’ve never made a decision that sounded good at first, but ended up being a disaster later?
Here are some areas where anti-patterns can occur.
Code Review Anti-Patterns
1. Too Subjective
In many cases, code reviews differ from developer to developer. Each one has their own set of pet peeves, working habits, and viewpoints. For example, five different developers can reject a piece of code for different reasons. Yet, a sixth developer may give this same code the greenlight. It goes without saying, this isn’t ideal.
2. Approval by Committee
Whenever you invite another developer for a code review, you’re adding another viewpoint into the mix. To make matters worse, that one person can have numerous viewpoints. What started out as a diverse mix can quickly become an angry sea of viewpoints and opinions. As a result, code reviews can turn into arguments about which solutions are better.
3. Gatekeeper
Have you ever delegated the code reviews to a single member of your development team?. Most of the time, it’s a senior developer or the technical lead. But then, disaster strikes. Here are 3 reasons why having a gatekeeper is bad:
- The gatekeeper thinks they have the “correct” answers. They also believe that everybody else should learn them.
- Team members stop expressing their own creativity. Instead, they feel encouraged to copy the gatekeeper’s style.
- The team’s productivity suffers. That’s because the code production needs to wait for one person to complete a specific task.
4. Cherry-Picking
Short-term rewards drive people. We all love that dopamine rush when we tick another item on our checklist. In this case, you write new code to finish your task. But, code reviews aren’t like this. They don’t give you the same rush because you’re only seeing how someone else tackled an issue. Where’s the fun in that? As a result, you can end up with a backlog of tickets within the code review queue. This can negatively impact your cycle time.
How to Fix Code Review Anti-Patterns
Code review anti-patterns can be detrimental to your team’s productivity. LinearB gives engineering leaders and managers so many tools to improve code quality. Our WorkerB bot allows you to streamline your code review process. In turn, you’ll improve your PR pickup time and overall cycle time.
See what this engineering leader said about overcoming bottlenecks:
Now, you know about some main code review anti-patterns and how you can resolve them. Let’s move on to the second category of scrum anti-patterns.
Developer Productivity Anti-Patterns
5. Comparing Velocity Across Teams
In general, teams weigh each story point differently. But imagine this: you’re comparing velocities across teams in hopes of motivating them to do better. But then, your developers find out and they start manipulating their story points to get better scores. If one or more developers are deliberately padding their story points, other team members will quickly catch on. Comparing velocities often leads to lost trust, resentment, and a compromised culture.
6. Using Velocity To Predict Project Deadlines
Can you use velocity to estimate delivery time for a multi-sprint long-term project? The resounding answer is a big NO. Capacity planning is only useful and accurate for a single sprint. Planning out user stories too far in advance is a waste of time. What good can it be to use changing metrics to predict an accurate deadline?
7. Stack Ranking Devs
Everyone always talks about the importance of developer creativity. But then we see some common practices that suffocate creativity. One of these practices is stack ranking. Some organizations rank team members against one another to find the best and worst performers.
Can you see where this might backfire? It discourages developers from joining high-performing groups. After all, if they do, they’ll have a higher chance of ranking low. It’s easier to join a poor-performing team and be the star of the show.
8. Focusing on Just One or Two Metrics
Velocity and DORA metrics are common developer productivity metrics. But what about other considerations that could have a stronger impact on code quality, data integrity, or developer experience and happiness? Unfortunately, only focusing on one or two metrics doesn’t give you a holistic view of your team’s performance.
9. #NoRetro
Your teams need retrospective meetings and sprint reviews to improve. Otherwise, their only chance to improve is when they meet outside of work. They might discuss problems, flaws, or solutions over coffee or lunch, or even after hours. But those meetings don’t even count! No one is keeping track of anything.
How to Fix Developer Productivity Anti-Patterns
To start, define your goals and the team culture you’d like to cultivate. Then, you can determine several metrics to track performance without undermining developer trust.
You can also use tools like LinearB to improve your productivity. For example, with LinearB’s Engineering Benchmarks, Team Goals, and WorkerB, you can look at leading indicators of productivity rather than lagging indicators like velocity and the DORA metrics. Get started with a free trial today!
Let’s now move on to another category of scrum anti-patterns.
Issue Tracking Anti-Patterns
10. Not Updating Jira Boards
We get it. Your devs would rather jump into coding to solve the bug or tech debt they just encountered than create a new Jira ticket for it.
You’re not alone. Our research shows 30% of most teams’ work isn’t tracked. But you’re making important business and strategic decisions from this incomplete data.
11. Scrum Master Does All The Issue Updates
Jira allows everyone on the team to collaborate easily. But it can be counterproductive if everyone sends their updates to just one person. Your Scrum master probably has more important tasks to do than reporting issues.
12. Using Jira as the Primary Communication Method
Some teams believe they can do away with meetings and scrum events by using Jira as the main communication channel. This is a harmful misconception. Take it from us: don’t do it. Sure, you can use Jira to start conversations and record results and decisions. But don’t even think for a second that it can replace in-person or online discussions.
How to Fix Issue Tracking Anti-Patterns
Another initiative around data entry hygiene that will most likely get ignored and comes at the expense of focused coding time. To this end, WorkerB bot can make this easier. This tool allows developers to create and update Jira tickets directly from Slack with the One-Click Ticket feature.
Improving your planning accuracy is next to impossible when you have Git branches unlinked to your issue tracker. So now that you have a solution to your data integrity problem, let’s look at sprint planning anti-patterns.
Sprint Planning Anti-Patterns
13. Sprint Stuffing
Imagine this: your team has been working on a sprint and you met the goal early. But instead of celebrating this achievement, the product owner urges you to fill in the extra time with tasks from the sprint backlog. This is referred to as “sprint stuffing.”
The truth is that meeting the sprint goal is already enough. Plus, the team has a number of other items that might require their attention during this extra time, such as refactoring parts of the code, fixing some bugs, or training on a new tool. Here’s a nugget of wisdom for you: Scrum in project management doesn’t aim to make the most out of your team members’ time.
14. Too Much Emergency Work
Have you ever had to work twice as hard just because someone sold a feature that doesn’t exist yet? In these scenarios, people generally promise delivery dates and set penalties for not meeting commitments.
This kind of external interference in the scrum process is never ideal. But sometimes, it could be necessary. The biggest problem here is when this behavior becomes the norm. If senior management doesn’t realize these situations are exceptions, they may jeopardize organizational implementation.
15. Pitching Directing to Devs
Some sneaky stakeholders might try to pitch directing to developers to squeeze in some minor tasks. However, the Product Owner should always be the judge when it comes to deciding how much time each scrum team member should devote to unplanned work.
16. Labeling Everything as a Bug
Some scrum teams offer an express lane for bug fixes and other critical issues. This way, they can implement pest control more efficiently. But sometimes, stakeholders abuse this feature. They start labeling all their tasks as “major bugs.” This defeats the purpose of having an express lane! These so-called “bugs” add work to the sprint and destroy the ability to deliver on your sprint commitments.
How to Fix Sprint Planning Anti-Patterns
Firstly, ensure everyone knows their limits in the sprint planning process. No one should be filling in the downtimes with extra work from the product backlog.
Additionally, when project delivery doesn’t go as scheduled, LinearB’s Project Delivery Tracker will help you understand what went wrong. How so? It links your investment profile to your planning accuracy breakdown. This way, you can see exactly where the added work is coming from and try to mitigate it.
Finally, we can move on to the last category of scrum anti-patterns that plague scrum teams.
Team Health and Culture Anti-Patterns
17. No WIP Limits
WIP limits dictate how many jobs a developer can handle at a time. And that’s good! In fact, you shouldn’t consider these limits to be too restrictive for your team. Having no WIP limits introduces extra queues, which reduces total developer productivity.
Additionally, your devs may be context switching between too many different open branches. This also wastes time! As a result, the cycle time might suffer.
18. Flow Disruption
Has this ever happened to you: one of the stakeholders is interfering and disrupting your team’s flow and productivity. Did you manage to meet the sprint commitment then? We’re thinking, no.
But did you know that even meetings can compromise your flow? That’s right–after any disruption, it takes about 23 minutes to get back into the zone and properly resume your work.
19. Lack of Support
During planning meetings, developers usually assign tasks that a single engineer can do in one day. But have you ever noticed that sometimes, a team member takes longer than expected to finish a task, but they don’t ask for help? In those cases, the scrum master should intervene and offer support. For this reason, all issues should be visible to the team. Otherwise, how can you offer help when it’s needed?
20. Micro-Management
For scrum to be effective, team members need to be able to manage their own development work. This means external stakeholders shouldn’t interfere. And whose job is it to ensure the team isn’t being micromanaged? You guessed it—the scrum master.
The master should intervene whenever product owners or anybody else tries to give assignments to developers directly. Stakeholders that try to gain command and control of the dev team should be stopped.
How to Fix Team Health and Culture Anti-Patterns
For starters, you should draw the line for anything that might interfere with your team’s independence and productivity. Consider using tools that also have this perspective. LinearB believes that engineering improvement starts with optimizing developer workflow. This means we want to help developers shave time off non-coding tasks through automation. As a result, your developers can get back to doing what makes them happy: coding.
Additionally, watch Katie Wilde explain why a manager should plan around the developers’ schedule to avoid wasting time lost to flow disruption and context switching.
Fixing Scrum Anti-Patterns
If you’ve been falling for any of these scrum anti-patterns, this article should be your wake-up call. And don’t worry, we’ve all been there. Scrum stakeholder behavior doesn’t always appear harmful, and other habits may not seem like such a bad idea.
That said, you should find ways to overcome scrum anti-patterns for a successful Agile transformation. Namely, here are 5 things you can try:
- Streamline your code review process with automation
- Use leading indicators, not lagging indicators to track productivity
- Uncover shadow work and keep your Jira tickets up-to-date
- Identify and remove bottlenecks to improve your planning accuracy
- Optimize developer workflow and eliminate external interference.
If you use tools like LinearB, you’ll help your team eliminate anti-patterns and adhere to the Scrum guide.
