First published in 2010, the Scrum Guide quickly explains the “rules of the game” to the global Scrum community. The service-centric role has evolved since, and arguably so have the Scrum Masters’ misunderstandings, which could also negatively impact your team’s effectiveness. Let’s explore some of the red flags that one might easily miss.
Scrum is the framework for agile project management—creating products that bring great value and delivering efficiently. The Scrum Master acts like a coach of sorts for the team, building a clear understanding of Scrum values, principles, and practices expected to display a cool set of soft skills. It’s not as easy to get it right as one may imagine.
In my decade-long journey to becoming a Delivery manager, I have observed some common flaws that a Scrum Master remains oblivious to while the team bears the brunt.
Here are 5 red flags to look out for:
If your Scrum Master appears to be in denial that a new project will bring a different range of complexities, builds a plan based on experience from other projects, and insists on steadfastly applying the “same-Scrum-for-all” formula.
Also, if your Scrum master is fixed on following the Scrum process a little too properly. Scrum cannot be played word to word by the book every time. Flag it if your Scrum Master puts method over outcomes.
The Scrum Master is not completely attentive to deriving maximum value from the interactions between the Scrum Team and other stakeholders, such as the Product Owner, the Development Team, and others in the organization outside the Scrum Team.
Having lost sight of product goals, you can see the Scrum Master struggling to establish clear roles and responsibilities and define realistic outcomes.
When your Scrum Master imposes authority, not allowing the team to think independently, experiment freely, or even make decisions that may be slightly contrary to what the Scrum Master has suggested, I fear your Scrum Master has forgotten how to play the role of a servant-leader.
On the other hand, there is the Scrum Master who only wears the leadership badge and stays busy running odd jobs for the team— from fetching sticky notes to scheduling meetings. This Scrum Master has forgotten about developing the team and helping it mature.
One of the principles from the Agile Manifesto states, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
If a Sprint Retrospective is treated like an add-on to be implemented only in free time, you have something majorly amiss.
Agile is all about adjustments, fine-tuning, and versatility. The Sprint Retrospective forces the entire team to pause to reflect on what transpired and discuss what worked and what did not during a project. Those who don’t learn from the past are doomed to repeat those mistakes in the future.
“If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail.” Abraham Maslow wrote in his book, The Psychology of Science in 1966. Popularly recognized as Maslow’s golden hammer, it speaks about the cognitive bias that involves over-reliance on a familiar tool.
Tools such as JIRA, Confluence, etc., may help in putting together the charts and dashboards as learned in Agile literature. However, tools, methods, and ceremonies alone will not build high-quality products for clients. Hope you don’t find your Scrum Master falling head-over-heels for popular tools.
There could be numerous reasons why a Scrum Master is rolling in the wrong direction. It could also sometimes be due to the sheer lack of organizational support, and at other times, the Scrum Master may not have received enough open feedback from all stakeholders. Whatever the circumstances, the only way to turn the flags green is to provide a helping hand to your Scrum Master to ensure your team is on the right track and avoid costly errors.
Scrum is a team game after all!