The Mechanical Scrum Pitfalls
Scrum is a framework based on an empirical process built on three pillars: transparency, inspection and adaptation. It is about having transparency in work processes and relationships, inspection to check if what has been done has generated value and adaptation to improve for the future. Being on the lookout for continuous improvement helps achieve business objectives.
You may have heard this definition before, however Scrum is much more than that. If someone tells you Scrum is a process, they are wrong. As I said before it is based on some processes but more importantly it is a mindset. The origins of Scrum are rooted in generating value for the stakeholders. Understanding this helps guide our day to day and even incentivizes making adjustments or concessions when necessary. Understanding the essence of the framework and the Agile Manifesto gives us a more comprehensive and less restrictive view.
It is also important to practice the values of Scrum, because it allows for the execution of a more dynamic and less mechanical framework. The 2016 version of the Scrum Guide — Scrum Agile framework guide — shows the following values:
A team with courage, focus, commitment, respect and openness, achieve self-organization, high performance and they prosper.
We decided to write this post because during our path as Scrum Masters, we have noticed that many times when we take the Scrum Guide too seriously we end up falling into some pitfalls, which make us lose track of what is most important in the world of agility: the delivery of value. Let’s look at examples of situations where this happens and how to act in these cases.
Scenario 1:
In the midst of a heated discussion, during feedback on the increment delivered at the Sprint Review meeting, here’s what the Scrum Master says: “Timebox ends in 20 minutes!”
Problem: Interrupting a discussion in the middle of a stakeholder feedback.
Solution: in a chaotic domain, it is the role of the Scrum Master to help those involved in the discussion reach a consensus (whether helping people organize their thoughts on the wall or using consensus techniques) or even take ownership of the discussion to make the team reach a conclusion within the predefined timebox. The best option, in this case, is to choose another time to carefully share with the Scrum Team the risks of finishing the meeting without a solution.
Scenario 2:
At a Sprint Retrospective meeting the Scrum Master decides to go through all the positive and negative points, regardless of the Scrum team’s fatigue.
Problem: not being sensitive to the team’s attention span and their responsiveness to the Scrum event.
Solution: Remember that in Scrum, people and relationships are more important than processes. Therefore, being aware of team fatigue is more important than going through all the points on the Retrospective board if the team isn’t being very responsive. It is good practice to take breaks, for example, you can use of the Pomodoro technique where you work in 25 minutes chunks and then rest for 3 to 5 minutes.
Scenario 3:
At a Sprint Planning meeting the Scrum Master states that since Sprint was four weeks long, the meeting duration should be eight hours.
Problems: According to the Scrum Guide, for a four-week Sprint the recommended timebox is eight hours, which means that the meeting can last from zero to eight hours. The Scrum Master is imposing practices without making sure they make sense in this real world context.
Solution: Scrum Master should try to optimize the Sprint Planning meeting as much as possible so that everything that will be done in the next Sprint is made clear to the Development Team. The discussions should be mutually agreed upon and there should be no interruptions for issues beyond the scope of what was defined going into the meeting. This prevents the meeting from being too long and dull. Ideally, eight hours should not be used, as this is the maximum duration for a one-month Sprint.
Scenario 4:
The Scrum Master defines that in a four-week Sprint (160 working hours), 16 hours have to be dedicated to Backlog Refinement.
Problem: The Scrum Guide says that although Backlog Refinement is not an official framework event, it is recommended because it helps make the Sprint Planning Meeting more productive. However, 10% is the maximum recommended time dedication that the Development Team should devote to this meeting, and it is up to the team to report the need or not of all the time being used.
Solution: It’s not because in the Scrum Guide the Backlog Refinement is mentioned that it has to be formally done. Ideally, the Development Team should identify whether or not the Backlog should be refined and not the Scrum Master. The Scrum Master’s roll it to only facilitate this meeting, and the rest of the burden falls on the Product Owner. As a facilitatorof the process, Scrum Master can explain to Devs the importance of having a refined Backlog like how it optimizes the Sprint Planning Meeting.
Scenario 5:
When seeing that the Development Team has a hard time talking to someone else’s client, they immediately interfere by trying to resolve.
Problem: When trying to solve the problems of the Development Team, the Scrum Master inadvertently discourages the team to do it alone. This can create a dependency relationship in which Devs come to believe they need the Scrum Master for everything.
Solution: Scrum Master just needs to ensure that he is encouraging the Development Team reach out to the client and if their difficulty with communication becomes an impediment, only then should the Scrum Master step in. The Devs should have already tried everything and still should be made responsible for this type of communication. The Scrum Master needs to create high performance teams that self-manage and organize to deliver value, even in their absence.
In summary, it is essential that we, as Scrum Masters, have full knowledge of our greatest reference, the Scrum Guide, so that we can exercise the instances inherent in our role.
However, if we do not analyze each scenario individually and do not carefully observe our surroundings, we run the risk of applying our knowledge in a way that does not generate value to those involved, which distances us from the main objective of the framework.
Taking into account the agile mindset helps us understand the essence of Scrum and prevents us from applying it mechanically. As a Scrum Masters, we must help the team understand and practice Scrum values so that with continuous improvement we can achieve better results. It is not up to us to always conform ourselves to the guide when it doesn’t apply to real world situations. Rather, it is the guide that must be adapted to better fit reality in these cases and we as Scrum Masters must always take into account the three pillars of the empirical process.
By Thiago Lima and Vanessa Franchi
This article was written in collaboration with Thiago Lima and originally published at: https://www.concrete.com.br/2018/06/06/as-armadilhas-do-scrum-mecanico/
