Not so Agile: 9 ways that companies do Scrum wrong

Here are methods for overcoming many of the pitfalls that companies frequently encounter when implementing the popular Agile framework

Gymmast falling off balance beam
REUTERS/Eddie Keogh

The use of Agile methods in software development (and even outside of software development) continues to grow. However, just because companies are trying to be Agile doesn’t mean they’re all succeeding. According to Jeff Sutherland, one of the creators of Scrum, the popular Agile framework, more than 50% of Agile teams are doing it wrong. The biggest failure? “ Not executing on the second value in the Agile Manifesto - working software at the end of a sprint that is tested and usable,” says Sutherland.

Earlier this year, Sutherland, the CEO of Scrum, Inc. along with Neil Harrison of Utah Valley University and Joel Riddle, also of Scrum, Inc. published a paper in the IEEE Xplore Digital Library titled “Teams that Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams“. In it, they outline the most common problems that Scrum teams encounter and methods (or, as they call them, “patterns”) for dealing with and resolving these issues. If your company uses Scrum, see if you’re familiar with these problems and, if so, consider their suggestions for becoming more - or truly - Agile.

Stack of unstable mugs

Frequently changing team members

Ideally, Scrum teams should be kept small, between 3 and 9 people, with some estimates suggesting that 5 is the optimal team size. But, just as important as the right sized team, is keeping the team membership constant for a reasonable amount of time. Removing people from the team or adding new team members at too frequent of an interval will hurt the team’s chances of success. In short, stable teams will learn their capacity which helps with predictability and ultimately increases productivity.

“If members are pulled off the team to work on other projects or are unable to participate regularly in rituals, the team’s Velocity will suffer.”

Man with a mouth-full of hot dogs
REUTERS/Carlo Allegri

Overestimating sprint points

Overestimating the amount of work a team can get done during a sprint is a common problem in Scrum. Sutherland, Harris and Riddle note that the best predictor for how many points a team will complete in the next sprint is the number of points it completed in the previous sprint (known as “Yesterday’s Weather”). A team that knows its capacity can avoid biting off more than it can chew which increases the chance of a successful sprint.

“Yesterday’s Weather allows teams to build a more accurate Sprint Backlog, limiting the possibility of the team ambitiously pulling in too many Estimation Points and endangering the Sprint.”

Man covered in bees
REUTERS/China Daily

Having too much work in progress

Scrum teams that have too much work in progress have trouble completing successful sprints. Instead, the authors advocate that teams “swarm” to tackle high value backlog items as a group in order to get them done as quickly as possible. Teams that take this swarming approach complete more work during a sprint.

“Swarming helps teams move items to ‘Done’ quickly, increasing Velocity.”

Road work sign which says Diversion

Inadequately allotting time for interruptions

Interruptions will happen during every sprint; that is, things come up, like bugs, that have to be addressed. A common problem among Scrum teams is not allocating the proper amount of time during each sprint to deal with issues that are not in the backlog. Sutherland and company recommend that teams estimate the amount of time to allocate for interruptions each sprint based on past experience. They also recommend aborting any sprint when the points spent on interruptions exceeds what was allocated; since this will likely affect delivery dates, this will incentivize the whole company to minimize interrupting the team.

“... teams that plan for interruptions do significantly better than teams that do not, even when they experience no interruptions.”

A real bug one a computer monitor full of code

Letting bugs linger

The core aim of Agile is working code at the end of every sprint. But Scrum teams should aim to have clean, working code at the end of each day. This means addressing bugs as quickly as possible as soon as they come up. Bugs that are not addressed quickly, but are left to linger, will take longer to fix in the future.

“... a bug that is not fixed the same day it is created can take as much as 24 times longer to correct three weeks later.”

Picture of a sign on a fighter jet saying Ejection Seat

Waiting too long to declare an emergency

As soon as it’s clear that a sprint is going off the track, teams should waste no time implementing pre-defined emergency procedures. Too often, teams don’t deal with a severe problem (e.g., too many items in the backlog) early enough in the sprint and time is wasted. It’s up to the Scrum Master to decide as early as possible when strong measures need to be taken, which can range from offloading some of the work to aborting the sprint.

“Do not delay execution while trying to figure out what is wrong or what to do. In a fighter aircraft you could be dead in less time than it takes to figure out what is going on.”

A highway with many impediments
REUTERS/Stephane Mahe

Allowing impediments to continue

Teams that don’t regularly identify and resolve impediments affecting sprint success are continually underperforming. Sutherland, Harris and Riddle advocate identifying the single biggest impediment in each sprint, creating a user story and resolving it during the following sprint. By regularly removing impediments, velocity will increase since teams will be able to get more done than in previous sprints.

“[Impediments] may deal with strong personalities, management impeding the Sprint, or a variety of sticky human issues. These impediments should be treated like process improvements and should be resolved as quickly as possible.”

A blue cookie with a frowny face on it

Not gauging the happiness of team members

When Scrum team members aren’t happy, it can negatively impact team performance. They could be unhappy with the company, the way the team works or their own role on it. The authors recommend that Scrum Masters regularly ask team members to rate their happiness level. Declining levels of team happiness should be investigated as soon as possible, which can help to identify roadblocks and impediments.

“By monitoring the team’s happiness, the Scrum Master can anticipate drops in Velocity and make adjustments.”

A speedometer showing a very slow speed

Failing to accelerate

Scrum teams that are not finishing the work allotted for a sprint are not improving. If they allot too much work for a sprint or fail to remove impediments or properly plan for interruptions they won’t be able to finish the work time and the sprint will fail. When these other common problems are addressed, teams will finish allotted work ahead of time, meaning additional tasks from the backlog can be addressed in the current sprint which will increase velocity.

“Teams that finish early also tend to have a higher Happiness Metric because they feel confident about their ability to complete Sprints.”