Common Agile and Scrum Anti-patterns

Recently, I was reflecting on some common anti-patterns I've seen over the years to try to put together a common list. And since there aren't enough anti-pattern lists on the internet, I figured it was worth sharing. LOL. In any case, I hope you find value, help or insight into identifying these in your own organization.

What is an Anti-pattern?

In case you're not familiar, anti-patterns is a term used to describe behaviors that are thought to be helpful, but are actually getting in the way or causing problems. Common reasons for anti-patterns include a lack of understanding of Agile, Scrum, an Agile Mindset or the unwillingness to let go of old habits that worked in a hierarchical, waterfall environment. Often times, the person exhibiting the anti-pattern behavior doesn't realize it.

Leadership and Management

Manage by metrics

Expecting status reports or daily updates is a sure sign there is a lack of understanding of Agile and Scrum. Forcing the teams to provide waterfall type status and updates takes focus away from delivering customer value. Scrum Artifacts, information radiators and the Sprint Review is how management should stay informed. Metrics should be used by the Scrum Team to help them improve, not by leadership to manage the team.

Comparing teams

Trying to normalize things like Velocity in order to compare teams to determine which team is better or producing more. Not only will the number of Developers on the Scrum Team have an impact on their Velocity, but Scrum Teams use relative sizing for estimates and every team’s estimates are only relative to that team. Scrum is a framework and every team’s process that develops within that framework is different. Scrum is about delivering value not output. Story points have no relation to value and comparing velocity (or anything else) across teams makes no sense.

Telling the team how to do things

Leaders should focus on providing priorities, direction, giving feedback and servant leadership. They need to trust and empower teams and let them figure out the best way to accomplish their work.

People are not dedicated to one team

Splitting people across teams is not only not fair to them, it leads to a loss in productivity due to context switching. Reassigning people regularly or having people split across teams disrupts the team and makes it harder to become more predictable, which makes it harder to forecast sprints and releases.

Getting Developers to work on “side-projects”

The Scrum team has one focus, the Sprint Goal, and they are committed to doing their best to achieve it. The priority order of work should come from the Product Backlog and emerge during Sprint Planning. Working on anything outside the Sprint also makes it harder to become more predictable.

Trying to go around problems instead of solving them

Scrum makes your problems painfully obvious. In a long waterfall project, it was easier to avoid fixing problems and just work around them. This is not an option in a short, time-boxed Sprint. Leadership needs to help or empower teams to resolve existing problems that make delivering a done, usable increment every Sprint challenging or even impossible. DevOps issues is a great example of this.

Hijacking Scrum events

Scrum is not a methodology, but it does have a flow and events have a focus on inspecting and adapting. Attending events and disrupting or hijacking them for their own objectives, like getting a status update, is hindering the teams ability to deliver value to the customer.

Don’t understand what an Agile Mindset is

Thinking you are just swapping out one process for another is going to lead to challenges. Enterprise Agility requires a shift in thinking and a culture change. It will fundamentally change how you run and manage your organization.

Having Leads on scrum teams

Leads were normal for Waterfall project teams. The idea that many decisions had to go through the Lead was part of the process. In Scrums short time-boxed Sprint, having one person that has to review, check, confirm or decide for all Developers becomes a bottleneck. The team needs to collaborate and make decisions together. That’s not to say that leaders can’t emerge during the course of the Sprint and use their knowledge and experience to influence others.

Everyone needs to be invited to the Daily Scrum

People who don’t understand Scrum think the Daily Scrum is a status meeting so they tell the Scrum Master to invite everyone who has anything remotely related to the work in the product. Let the Developers use the Daily Scrum as they see fit to best achieve the Sprint Goal.

Project focus instead of Product focused

Moving from project to product focus will have a huge impact on the ability to deliver value through stable, product focused Scrum teams that are more predictable. Moving to funding product teams annually, over the never-ending project budget planning, will save time and money while allowing stable teams to focus on delivering value.

Creating a dual Scrum Master/Product Owner role

This is often the result of a lack of people or buy-in to moving to Agile and Scrum. This tends to lead to a “let’s try it out”. There is nothing wrong with experimenting to see if Scrum is right for you, but the Product Owner is responsible for maximizing the value of the Product and it’s a full-time job. Expecting someone to take on a dual role, will limit the Product Owner’s ability to do their job well and result in a less effective Scrum Team.

Thinks the Scrum Master is a Project Manager

Without an understanding of what Agile and Scrum are, some leaders look to Scrum Masters to provide status reports and updates, just like they always did. Scrum Masters need to take the opportunity to train and coach leadership and management about Agile, Scrum and the many hats of a Scrum Master.

Proxy Product Owner

Having a proxy who can’t make decisions will lead to delays. As the person responsible for maximizing value, the Product Owner is a key role on the Scrum team.

Product Owner

Using the Product Backlog for ideas

The Product Backlog is the single source of information needed to improve the product. Avoid using it as a repository for ideas or anything else not related to work needed to done by the Scrum Team.

Unavailable Product Owner

During the Sprint, the Product Owner needs to make sure they are available for the Developers. Developing complex products leads to learning and discovering new things, not to mention general questions about a feature being implemented. The Product Owner needs to make sure they are addressing the teams Sprint questions in a timely manner. 

No themes or Epics/Creates stories from a requirements document received from Stakeholders

Instead of working with stakeholders through product planning events, the Product Owner just asks them to deliver a requirements document like they used to. Then just copies and pastes the requirements into stories. At every level we should be planning with a focus on delivering value. Features should emerge through product planning and prioritization efforts and breaking down of big ideas and stories into smaller ones.

Include how when creating User Stories

The Developers decide the best way to implement the work. That doesn’t mean the Product Owner can’t discuss it with the team, they just shouldn’t tell them how to do it by putting the how in the story.

Component based stories

It’s hard to measure the value to the user when the story is not user focused. It also creates dependencies and makes it more challenging to order the Product Backlog. In a cross-functional team, what were component stories become the sub-tasks of the user story and emerge during sprint planning as the team determines how to accomplish the work of a user focused story.

Missing acceptance criteria in stories

Acceptance criteria is a key part of story that focuses on the functionality of the story. It also helps guide those developing and testing the story. Without acceptance criteria, how will you know if the work is complete?

No Sprint Goal

The Sprint Goal is the single objective for the Sprint and provides guidance and focus for the team not only during Sprint Planning when they are selecting PBIs, but during the Sprint when they are working towards achieving the goal.

Not breaking down stories into small increments

A User story is one piece of functionality that provides clear business value. Breaking down stories into small increments makes it more likely the work can be completed in the Sprint as apposed to getting most of a larger story done and having to carry it over to the next Sprint. This means faster feedback loops. This can and should happen in refinement, but the Product Owner should be thinking about the smallest feature they can implement.

Scrum Master

Not a change agent

The Scrum Master is accountable for leading and helping the Scrum Team and the organization in adopting Scrum and establishing Scrum Theory and practices. This may include challenging the status quo and coaching people in understanding why we do the things we do in Scrum.

Does work for the team

By doing work for the team, the Scrum Master becomes an impediment to the team self-managing. The Scrum Master serves the team. Resist the challenge to do the work of the team, instead take advantage of the opportunity to Mentor and Coach them.

Avoids conflict instead of resolving it

In the complex domain, healthy team conflict should be expected. But when conflict crosses the line it needs to be addressed, potentially in the Retrospective or one on one as appropriate.

Uses the same Retrospective format every Sprint

Finding ways to improve can be a challenge for some teams. Mixing up the Retro may help draw out ideas and conversation. We should also be reviewing the Definition of Done and Team Agreement from time to time.

Running meetings instead of facilitating

Scrum Masters should be facilitating meetings, not running them. Facilitate to help the team reach their goals and take advantage of coaching or mentoring opportunities as they present themselves.

Acting like a Project Manager

Scrum Masters wear many hats, Project Manager is not one of them. If you’re taking meeting minutes and sending out status reports, stop! Let the transparency of your artifacts, information radiators and the Sprint review provide information about your Product and the team’s work. As stated in the Agile Manifesto, face to face communication is also a great way communicate.

Cancels the retro

The Scrum Master is accountable for team effectiveness. This includes facilitating Retro’s to identify ways to eliminate waste and improve delivering value faster.

Developers

Sizing by relating story points to hours

One of the more difficult transitions is moving from absolute estimation to relative sizing estimation. It takes time and focus. Don’t worry about trying to be exact. You can become more predictable using relative sizing estimation and it’s easier and geared toward teams.

No time for improvement

Sometimes due to pressure from management teams feel like they don’t have time for improvements. It is a necessary part of Scrum and should not be overlooked.

Using Daily Scrum for status reporting

Reporting a status to the Scrum Master is how many Daily Scrums start on new teams. The Daily Scrum is for the Developers. Use it in whatever way helps you best achieve the Sprint Goal through discussion, planning and adapting.

Making stuff work for the Sprint Review when it’s not done

If it’s not done, it’s not done. Don’t waste time making something work temporarily for the Sprint Review.

Hiding technical debt

We should be addressing technical debt. Not being transparent about technical debt is just going to come back to bite you. We need to be open with the Product Owner and Stakeholders about technical debt since resolving it at some point, means delivering less value.

Using something other than the product increment for the Sprint Review

The Agile Manifesto says we measure progress through working software (or product). The Scrum Guide says we should produce a done, usable increment at the end of every Sprint. Nix the Powerpoint slides and screenshots. Show your working product in the Sprint Review. Otherwise, you are losing transparency and may not adapt appropriately.