Scrum Smells: When Good Goes Bad

Scrum is used by 66% of all agile companies. But is it really that good or just a tribute to the agile fashion? If you’ve tried to implement Scrum, you’ve likely run into problems. This management framework may look simple to understand but it’s hard to master. Getting dedicated people to support Scrum implementation is even harder. No wonder many teams get it wrong.

Here are the most common things that make good Scrum implementation go bad.

1. You’ve lost the rhythm

When Scrum is well-executed, the team establishes a certain rhythm. Each Sprint has the same length, it starts with a Sprint Planning meeting and ends with a Spring Review.

If some of your Sprints last two weeks and others – four weeks, the rhythm is never established. When the team is allowed to change the length of Sprints, it becomes harder to select the right amount of work for the Sprint Backlog and often leads to the decrease in commitment and productivity.

2. You over practice scope-stretching

The team may decide to increase the scope mid-sprint. Many developers view it as a good thing: they want to exceed customer expectations so they add improvements that were not requested. The problem is, scope-stretching often delays the work that was prioritized during the sprint planning.

The same thing happens when stakeholders distract developers from the work in the sprint with small requests. Though they seem harmless, it takes time for a developer to switch from one work to another. If multiple developers get distracted multiple times per week, it becomes a huge problem.

3. You fail to describe clearly what you want to get at the end of the sprint

Communication your vision is not easy. You may think you’ve described everything clearly but your team could have heard something totally different.

If you don’t want to get Y instead of X, during the sprint planning meeting ask the team to explain the business requirement in the own words. If they can’t, this is clear sign there is a gap in communication.

4. You fail to identify bottlenecks

If your team is constantly reporting they can’t do X because they don’t have Y or are waiting for Z, there is a problem with identifying and addressing bottlenecks. Make sure the Scrum Master takes care of the team’s needs and work to remove obstacles by even making calls and getting signatures for approval.

5. You are missing people at the daily Scrum meetings

Having daily standups and having them at the same time and place helps the team establish its rhythm. If too many people who are committed to the project start avoiding Scrum meetings on a daily basis, this is a clear sign the meetings either take too long or have little value. This is when the situation begins to smell.

6. You are not learning from past Sprints

Let’s take a team of three. They start a sprint with an estimated 400 hours of work. In the middle of the sprint, they realize they scheduled too much and agree to remove 100 hours. When planning the next sprint, they again put 400 hours of work. If they team can’t explain why they think they can achieve 400 hours this sprint,  they are falling into the same trap again and not learning from their previous performances.

7. You let the Scrum Master assign work

Self-organization is one of the Scrum backbones, which means developers sign up for work. When work is assigned by the Scrum Master, it contradicts the Scrum principles, undermines developers’ responsibility and makes them feel they are out of control of their own work.

The Scrum Master should never assign tasks to team members and protect the team from anyone else who is assigning tasks.

8. You turn the daily Scrum into a status update

The main goals of the daily Scrum are project coordination and task commitments: team members hear what everyone else is doing and make task commitments in front of their peers. This is a huge motivation for the team members to complete on time whatever they’ve committed to.

But when the daily Scrum turns into a status update where the ScrumMaster is collecting information about who has failed or is behind schedule, such meetings lose value and become demoralizing.

9. You let the team members avoid responsibility

When your Scrum team has highly specialized job roles, it allows the attitude “it’s not my business”. For example, if your team includes a dedicated “tester”, then this may give the rest of the team an opportunity to avoid the responsibility to test.

It doesn’t mean your team should consist of “generalists” (clearly not everyone can be a DBA or write .Net code.) But in order to be successful, each team member should accept responsibility for the system as a whole.

Has your team faced any of these “smells”? How have you “neutralized” them? Share your thoughts in the comment.