Now that we have already talked about the results we had using Scrum at ClubPetro, I feel obliged to tell you about some of what I consider to be the main mistakes when using Scrum, which is also the most common to happen.

The main and most common mistake when using Scrum is not following the first principle of the Agile Manifesto for Software development, which says:

Individuals and interactions more than processes and tools

The main mistake when using Scrum

One of the mistakes that we see most happening when using Scrum is having the Scrum Masters applying the methodology in an extremely plastered way, without even considering any change in it. In doing so they are putting the process before people. The thinking is “the Scrum I learned is a perfect methodology that does not need to be modified for any team, they must adapt to the methodology”.

The biggest mistake when thinking this way is that you make your teams adapt to the methodology exactly as it was described, without thinking about how it can help your team, but thinking that if your team adapts to this box predefined, the results will grow by themselves.

This thought that we talked about in the previous paragraph is not an agile thought. The reality of each of your teams and the challenges they face are different. While one team may not have much uncertainty, not having to perform any unplanned tasks, others may have more uncertainty. Teams with more uncertainty usually have to include more tasks during the Sprint.

This is the first change I made when implementing the methodology at ClubPetro: changing the duration of the Sprint to suit the reality of each team. While in Marketing we had very little uncertainty, most of the time without the need to include any new tasks in the middle of Sprint, in our Customer Success team we had an extremely greater burden of uncertainty. This led the team to have to include unplanned tasks more often, causing sometimes more than 20% of the work to be done to be unplanned, which is not ideal.

Solving the first mistake

To solve this problem mentioned earlier, we reduced the Sprint time for this team from 2 weeks to 1 week. With that, we were able to add the tasks that were extremely necessary and appeared in the middle of the Sprint without ending it completely differently than planned. With that, the tasks that could be accomplished in the next week (in the next Sprint) were prioritized in the Backlog so that we would not forget them.

So my first tip is: for teams with greater uncertainty, perform smaller cycles. Thus the adaptability increases and the Sprints are not uncharacterized.

Second biggest mistake

The second of these big mistakes when using Scrum that I saw and that generated the second change that I made in some teams was simply to modify the Daily Scrum. This change was made due to the fact that some teams were using it as a transfer meeting and nothing was done about what was discussed there.

To modify this meeting, I made a simple change to the questions that were asked to guide the conversation. We changed from the classic three questions of the Daily Scrum:

  • “What did you do yesterday for the Sprint’s progress?”;
  • “What are you going to do today to accomplish the Sprint?” and;
  • “What were your impediments from yesterday to today?”.


  • “From what committed on doing yesterday, what did you do?”;
  • “What do you commit to finishing today for tomorrow?”;
  • “What stopped you from doing what you committed yesterday?”.

This change causes teams to commit to what they are going to do and to have greater control over what is being done. The tasks that the team that undertakes to perform are pulled into the “Doing” column and those responsible are already defined.

With that, on the next day, we were able to find out if the tasks that each member undertook were accomplished or not. If one or more has not been done, we have already focused on the impediments that hindered this from being done. This approach creates greater dynamism in the Daily Scrums and the team sees much more value in the ceremony.

Remember this when implementing Scrum

As a final reminder and warning, I say to you: always remember the first principle of the Agile Manifesto. Do not treat Scrum as a Bed of Procrustes and try to adapt your teams to it. Adapt the methodology to your teams and you will see your results absurdly better. Count on Roads to help you achieve these results!

Sharing is Caring!