What happens when the ScrumMaster becomes so overzealous that their message is rejected? Over the past couple years, I have seen this situation play out in several companies that I have worked with in depth. The situation is such that a person who has the role of ScrumMaster gives the “woe is me” response to how well things are going with the team or teams they are working with. Nothing seems to be going right when you talk to them. However, when looking at the team, they consistently deliver working solutions. They collaborate and make consistent changes. They are learning and growing, albeit not in a perfect fashion. The person that is designated as ScrumMaster has a response that can only be compared to that of Chicken Little. Yes, The Agile Sky is Falling!!! The reality is usually far from what that ScrumMaster is saying.
Continuous improvement with a team is a very important thing. When a team starts to stagnate, it can be frustrating to determine what to do next with a team or members of a team to help them be reignited by the transformative power of an agile mindset. For a ScrumMaster specifically, It becomes important to have balance among all things. They don’t always have to be right about things going right or wrong within the team. Sometimes failure and success need to be experienced first-hand for a team to be motivated to move along the path towards agility. Theory needs to be coupled with a pragmatic approach to help make a message palatable. Sometimes the correct approach is not what the theory teaches but it is more about adapting to become more agile in your approach. If the ScrumMaster is constantly pushing a message that is being rejected, regardless of whether they are right or not, the message falling on deaf ears will make the ScrumMaster viewed as ineffective. That’s right, even in being correct they can be viewed as ineffective. Perhaps more so than anyone else in the organization, the ScrumMaster needs to have the agile mindset to adapt with the team incrementally and to challenge them to the next steps going forward.
Take a couple situations for example:
A team is not using sprints but using Kanban because the team doesn’t like the structured planning meetings…. Why don’t they like the planning meetings? Is there value that comes from them? What is missing? Usually it is how the message is delivered when discovering the underlying concern. If priorities continue to change within the sprint, is it really a sprint? Some teams set aside a small percentage of time within their sprint for unknown production issues that may come up. Is it wrong? Yes, from a strict Scrum perspective it is. Does it help them at least identify the obstacles that are consistently happening? Yes. How do they decide to address those obstacles in the future? Avoiding just keeping it status quo is the job of the ScrumMaster to challenge them to improve so they can have a productive discussion around how they want to change what is sustainable to them.
In another situation, a team continues to pull as many user stories as they have developers on the team to complete during a sprint. At the end of a sprint, there always seems to be 1 or 2 user stories that are not getting completed. What is causing this? While there may be many things that are causing it, a strict interpretation of limits within the team suggests that everyone should swarm around one user story until it is completed and then move to the next one and so forth. In sharing this message with one developer several months ago, I remember his response. “Well, I’d like to do something to feel like I am useful also.” The team discussed the value of peer reviews, automated testing and several other items to be worked on with each user story. However, the team decided to bring in another user story so this developer could feel like their contributions were worthwhile for the sprint. In the end, the user story was not finished and the ScrumMaster could’ve pulled out the “I told you so” card but it was not pulled. Discussion about what was learned and what caused a couple user stories to not get completed helped with root cause analysis. It was several more sprints before the same messaging came up and the same developer was now ready to hear it and follow advice on not taking on more items but helping to get finished what was committed to within the sprint.
In any situation, if you find yourself sharing the same message over and over, you run the risk of being marginalized. When the ScrumMaster finds themself in this situation, it is very precarious because they are viewed as being overly dogmatic and unable to adapt. The team then adapts without the ScrumMaster and resentment can settle in that they decided to make changes that are different than what was recommended. Overall, the ScrumMaster needs to be the advocate of the team to the business and help them adapt to become more agile. Steps backwards, to the side and forward are all steps towards progression. Don’t become marginalized because you are pushing the team to do something they are not ready for. The much more effective ScrumMaster finds the in-between steps to get to the end goal. The dead ScrumMaster is not an effective ScrumMaster. Don’t become dead to your team(s) but be vibrant in your ideas and open to new ways of getting to an end goal regardless of whether you think it will help or not. Your willingness to be openminded will help the team to also be openminded and try things that will help them be more agile in the short-term and long-term. Don’t be dead, be agile!