Top 10 Mistakes Scrum Teams Make
11 March 2016
During the years that I've been working as a ScrumMaster, I've seen some typical mistakes that disrupt a Scrum team. They slow the team down and prevent them from reaching their best level of performance. Because mistakes don't necessarily surface at the beginning of a Scrum implementation, they are difficult to prevent, and sometimes they are even difficult to detect. I keep this list written down so that I can come back to it occasionally to make sure that we aren't making these mistakes.
Mistake No. 1: Too many tasks in progress
Imagine this scenario: Your team has just started working with Scrum, and the number of tasks is increasing exponentially because of the many different impediments (maybe your deployment system is not ready, or your stories are still not mature enough). Because a task cannot be completed, the developers start a new task or story. You are almost at the end of the sprint, you realize that most of the stories are in progress, and you have almost nothing done (according to your Definition of Done).
Now imagine that you continue with the next sprint and the same situation happens. The only problem is that you now have new stories and old stories. In my experience, it is at this moment that the stakeholders become nervous and start pressuring the team. As soon as the team feels pressure, one of the reactions is to start taking on more tasks and working in parallel, all the while thinking that this makes them faster or more productive.
It is a well-known principle from the Lean philosophical framework that working on many things at the same time brings waste into the process. In Scrum, we are looking to prevent waste by focusing on a constant flow and pace in our delivery. If your story is not done yet, you continue working on it before starting a new one. Sometimes, part of the task involves waiting. If this is the case, then you can use that time to help someone else, maybe by pair programming or by testing. One phrase that is useful to remember comes from the Lean philosophy: "Stop starting and start finishing."
Mistake No. 2: Behavior-oriented management
For many years, companies have used behavior-oriented management to improve their processes. They tried to control the behavior of their employees by attempting to measure it. They introduced work clocks to measure how many hours they dedicate for each task; they even tried to control how much time each person should spend on breaks.
This is still a challenge, even for ScrumMasters. I remember one developer who took a lot of breaks and who was not really open to talk with other people. At one point I was disappointed with him, but then I realized that we were reaching our goals, the customer was extremely happy, and the team was working at a constant pace. It took me some time to learn this, but now we try to concentrate on measuring things that are important, like customer satisfaction, quality, and, of course, the goal of the sprint.
Mistake No. 3: Not having a clear goal
This mistake still appears in some of my sprints. After each sprint, the team should have a main goal. The reason behind it is that it helps the team by setting a direction. It is really important, and it is not easy to do. I've seen some goals like "Fix all bugs," "Finish all stories," "Do five stories" -- which might seem correct, but they are too general or too restrictive.
The goal should be clear, measurable, testable, and negotiable. Furthermore, there should be several ways to reach that goal, and it should give the developers the freedom to think about alternatives. An example would be: "The goal is to provide the user with an alternative method to pay for our products."
Mistake No. 4: Making decisions for the team
Sometimes the stakeholders or managers want to speed things up, and they start making decisions without consulting the team (I've seen this also with ScrumMasters). The reason I have heard most often is that they think that the team will take too much time to decide, and they can't afford it. The second reason I hear often is that they see that the team is not participating and not being proactive.
Any decision that you make on behalf of the team takes the responsibility away from them. This responsibility helps with motivation and makes good teams great. You will need to be patient; a team that makes decisions will need some time, even more time if they were never given the opportunity to exercise decision-making previously. Instead of making the decision, you can focus on helping them reach a consensus (for example, through workshops).
Mistake No. 5: Focusing only on efficiency
If we have learned anything about industry and machines, it is that searching for efficiency is important for things like reducing costs and making more profit. The problem is that in some environments we might need to sacrifice efficiency for resiliency. Consider a high-speed road. If we used the whole capacity of the road, then every single space would be filled with cars. This would not really deliver the desired results. You need some space between cars to let them maneuver and travel at higher speeds. You need to sacrifice what seems to be efficiency to allow the system to adapt to its needs.
This is also true for development. Your developers need time to relax, to think, and to learn. They don't need to be busy 100 percent of their time. Give them a little bit of space so that they can adapt to whatever is happening.
Mistake No. 6: Trying to centralize control
I have seen this in big projects in which there are many teams that need to coordinate with each other. In those cases, some managers wanted to have control over everything. They asked for written reports, attended meetings to ask for status, asked for time estimation and plans, etc. This might not seem bad in a small project, but in complex projects it is almost impossible to know what is happening everywhere. Understanding the system as a whole is something that can't be done in that way under a complex system.
Instead of trying to control the whole project, make sure to have diverse teams that can self-organize and work on improving the interaction and communication among themselves.
Mistake No. 7: Missing visualization
There are several online tools on the market that provide nice visualization of your projects. The mistake comes when we focus only on that. Having an online tool is good, but the physical visualization is also important: Scrum boards, calendars, whiteboards, and diagrams. They let you have quick conversations with your team and with stakeholders but also remind you of your goals and past decisions. When I started as a ScrumMaster I didn't think it was important, but after some time, I discovered how useful it is to have visualization in your room.
Mistake No. 8: No team-building activities
Do you remember when you first introduced Scrum or Agile inside the company? Maybe you gave some presentations, prepared a few games, and even prepared some team-building activities. As time passed, it looked like everything was going well, and the number of activities was reduced to the point that you just stopped doing them. It is true that you cannot give a presentation every day, but in my experience, you should continue with them. Holding team-building activities once in a while helps the team stay motivated and increases team spirit.
Mistake No. 9: No environment in which to fail
As you navigate through the sea of continuous improvement, your team will come up with ideas they never tried before. Some of those things will work and some will fail. Your team needs to know that it is OK to fail, because this is the way they learn. This can be done only if you prepare a safe environment in which to fail. For example, for one of my teams, we use to put our "experiments" on a board, and we tested them for one month. If there was a good result, we continued with it; if not, then we just took the next one and tried it. It was clear to everyone that this was the purpose of the meeting.
Mistake No. 10: Forgetting about quality
It happens sometimes that a team forgets about continuously improving the quality of their deliveries. The team relaxes and stops thinking about ways to improve. It is important for us to remind the team as frequently as possible about trying to reach a higher level of excellence. Practices such as pull requests, pair programming, unit testing, or integration testing can help the team to reach new levels of productivity.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.3 (13 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.