Share This Page


Share This Page


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 difficult to do really well. Here are 10 common Scrum mistakes and how to avoid them:

1.Expecting transformation to Agile/Scrum to be easy. All too often someone will pick up a book on Agile, 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 to the hard parts. Performing techniques without understanding why they are doing them leads 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 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-organized, 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 to overcome challenges. Often the lesson is learnt better by experience (good or bad experience) than by just being told what to do. Allow the Scrum team to figure things out 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 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 and provide all the training and help the Product Owner needs 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. His 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 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, provides visibility and transparency into the project, etc. For such a key meeting, it’s important to set the right expectations upfront so that the team takes it seriously. This may sound militant, but to me attendance at the daily stand-up is never optional. I start exactly on time and never go beyond 15 minutes. We answer only 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). I don’t allow side conversations, discussions or problem-solving during the meeting; 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, I 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; constant improvement is.


About the Author

Dwight Kingdon
Program Director - Agile CoE

Dwight Kingdon is an Agile Coach at Mindtree. He is a thought leader in Agile methods and best practices, leveraging many years of software development, analysis, project management and leadership experience. Dwight has 25+ years of project management experience leading complex information technology projects, and over nine years of Agile/Scrum experience coaching and leading high profile, mission critical projects.

Other Stories by the Author

Let's Talk About Your Needs

Thank you for your submission. We'll be in touch.