10 Common Scrum Mistakes and How to Avoid Them

When most people think of Agile, they think of “Scrum”.  Scrum is the most widely used, and arguably, the most abused Agile framework.  Scrum is simple in concept but can be difficult to do really well.  Here are 10 common Scrum mistakes and how to avoid them:

1. Expecting Transformation to Agile and Scrum to Be Easy

All too often, someone will pick up a book on Agile or Scrum, start chopping up requirements into user stories, begin daily stand-up meetings, develop software in 2-3 week sprints, and then call themselves Agile.  Easy, right?  They will likely see some improvement in their ability to respond to change, and may even provide working software faster – for a while.  It won’t be too long, though, until the promises of Agile become less evident, teams struggle to keep up the pace, software doesn’t always match user expectations, and then Agile is deemed a failure.  Agile transformation takes time and almost always starts out messy.  Real transformation exposes existing corporate and culture problems that must be dealt with – problems such as poor communication, lack of accountability, distrust, etc.  Effective Agile transformation is often a total culture change.  Give it time, and be ready to go through the pain and resistance to cultural changes.

2. Doing the Practices Without the Principles

Doing the easy things like implementing Scrum meetings, filling the Scrum roles,  and using proper Scrum artifacts is good, but is only half (or less) of the battle.  The Agile principles are what make the practices work well, and make them sustainable in the long run.  Principles are much harder to incorporate than practices, which is why many companies fall short – they don’t do the hard parts.  Using techniques without understanding why you are doing them can lead to frustration.  Agile is about people, interactions, and culture, not processes, practices, and tools.

3. Complicating the Agile/Scrum Startup

Do everything you can to keep Agile startups simple.  Agile projects can be successful without the latest, coolest collaboration or lifecycle tool.  Stickies on a wall, tasks in a spreadsheet, and a manually generated burn-down chart will get the job done.  Spending valuable time getting a tool up and running instead of getting people working together is focusing on the wrong thing.  The Agile Manifesto places higher value on individuals and interactions than on processes and tools.

4. Leading a Scrum Team Like a Project Manager

A “command and control” mentality is counter to the Agile framework.  A leader assigning tasks and dictating effort is an Agile anti-pattern.  Great Agile teams are self-organizing, the Scrum Master is a servant leader, and teams learn to become better at working together and delivering greater value more efficiently by regular inspection and adaption.  Often the lesson is learned better by experience (good or bad experience) than by just being told what to do.  Allow the Scrum team to figure things out for themselves, to make mistakes and learn from them, and to attain the satisfaction of becoming a productive team on their own.  Scrum Masters and Agile coaches guide more than they drive.

5. An Un-Ready Product Backlog

A product backlog that isn’t “ready” is one of the most common reasons for sprint failure and for unmotivated teams.  It is also a root cause for low delivery velocity and not delivering high value.  Most new Product Owners aren’t ready to be productive on their own.  They need instruction, coaching, and hand-holding for the first few sprints as they learn to develop and maintain a product backlog that has enough valuable features estimated at a high level, and prioritized by business value.  Preparing the backlog well ahead of the next sprint(s) is a must.  You never want the team to run out of work to do, and that work must be of highest value at that point in time as prioritized by the Product Owner.  Being a Product Owner can be time-consuming.  Set the right expectations, provide all the training, and help the Product Owner to keep the flow of value coming.

6. Communicating “Through” the Scrum Master

Something I see quite regularly on new Scrum teams is people using the Scrum Master to deliver their messages to others.  For example, a developer has a question about a user story; instead of going directly to the Product Owner, he/she emails the Scrum Master to obtain the information.  A key Agile principle is communicating face-to-face whenever possible.  The time it takes to compose the email would likely have been all that was needed to get the answer directly from the stakeholder.  But, for many technical people, face-to-face communication is a scary thing when they’re used to living in their cubicle world, without having to talk to people.  This is a cultural or personality issue that must be overcome.  It wastes time and, more importantly, increases the risk of miscommunication.

7. A Product Owner Who is Not Available Or Involved

The Product Owner role can be very time-consuming.  Many who are new to the role are not ready for the commitment, or just don’t know that they need to be so involved.  Collaboration is critical in the Agile world.  Business people and developers need to work together to produce software that the business wants.  This happens by constant communication, collaboration and short feedback cycles to validate or make course corrections.  A practice I love to see is the Product Owner so involved in the day-to-day activity of the project team that the Sprint Review is purely a formality because the Product Owner has already seen several iterations of the features throughout the sprint and has guided the team to build exactly what the business wants.  That’s a beautiful thing.

8. Lax Daily Stand-ups

The daily stand-up meeting is very important from several aspects.  It puts people face-to-face every day for 15 minutes, forces communication and collaboration, and provides visibility and transparency into the project.  For such a key meeting, it’s important to set the right expectations up front so the team takes it seriously.  This may sound militant, but attendance at the daily stand-up is never optional.  Start on time and finish on time.  Stick to the three questions (what did I accomplish for the project yesterday, what will I work on today, what obstacles are blocking me from completing my work on time).  Don’t allow side conversations, discussions, or problem-solving during the stand-up; those can all be done after the stand-up is finished.  This gets the team in the mode of respecting the team and people’s time, and they learn to communicate better by sticking to the objectives and being succinct.

9. Not Raising Obstacles Early Enough

The daily stand-up provides the opportunity every day to communicate impediments to getting our work done.  One of the primary functions of the Scrum Master is to remove obstacles so that the team can focus on delivering software; but if obstacles are not raised, the Scrum Master can’t help remove them.  Waiting to raise an obstacle until it’s too late to recover from it is unacceptable.  Until team members are accustomed to communicating obstacles in a timely manner, remind the team at the beginning of every stand-up to bring up even potential obstacles, or if there’s any chance something might delay their work or cause them to not live up to their sprint commitment.

10. Not Conducting Retrospective Meetings After Every Sprint

One of the twelve principles behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.  Unfortunately the Sprint Retrospective is often treated like an add-on or a luxury, and performed only “if there’s time”.  The fact is, Agile is all about adjustments here and there, fine tuning and responding to change.  It’s really hard to adjust and fine tune if we don’t pause to find out where adjustments are needed.  The status quo is not Agile; continual improvement is.