Enabling continuous improvement is a beautiful thing, but it also involves dealing with and embracing a lot of ugliness. It’s a masterful dance; some moves might be rehearsed, but a lot involves intuition.
Understanding Scrum
How well do you understand the Scrum Guide? Do you know why the guide says what it says? How well is this understood by others in the team? or those involved with the team?
I’ve lost count of how many times I have read the guide. I constantly validate my assumptions with the guide and community. It doesn’t really get dull, as with growing experience the Scrum Guide provides new insights time and again. I love those moments of epiphany.
Referring to the Scrum Guide can be very helpful during moments when you are not sure, or when there is a dispute. Just like checking the rulebook during a boardgame. The rulebook isneutral as long as it is respected by all players involved. Just know that often this is not the case.
The Scrum Guide, however, doesn’t explain how the Scrum Master is to fulfill the accountabilities.
Services to the Product Owner.
As a Scrum Master, you not only help everyone better understand the guide but also help them in fulfilling their accountability.
When it comes to the Product Backlog and determining priorities, a Scrum Master might point out to a Product Owner that MoSCoW (Must Haves, Should Haves, Could Haves, Would Haves) is not the most transparent way to prioritize. A top-down list, however, gives everyone a clear sense of how things stand and what the team will be focussing on first.
A Product Owner will deal with impatient stakeholders who will demand guarantees and dates of delivery.
A Scrum Master will explain to stakeholders (and Product Owner) the value of attending reviews and the value of the team being able to adapt to new insights, changing conditions, and newly discovered complexities. The Scrum Master might intervene when stakeholders pressure teams to make promises that could impede the team's flexibility.
Services to the Developers.
The Scrum Master is there to empower Developers in managing their own work(flow). The worst way a Scrum Master could do this is by managing it for them. Doing this robs the Developers of their accountability and makes them complacent. The Scrum Master is not there to direct the team but to guide the team.
The Scrum Master will help the team be productive, creative, and adaptable. The Scrum Master can facilitate the Scrum Events and other interactions when requested or needed, and help team members adhere to the Sprint Cadence and time-boxes.
A Scrum Master may act as a representative to the team to empower them in improving their working conditions.
Scrum Masters will work with other Scrum Masters, to exchange experiences and possibly to validate certain approaches. They might also enable cross-team collaboration. They’ll understand that what works for one team, might not work for another. They’ll refrain from comparing team performances, but rather, inspire teams to learn from one another.
A Scrum Master may struggle with members who fail to follow up on actions and commitments to fellow team members. They’ll have tons of ‘excuses’ ready. It’s not a Scrum Master’s job to hold them to it, but to make transparent what the impact is of not meeting them. What impact does it have on the team? trust? the product? one’s own professionalism and reliability?
Services to the Organisation.
The Scrum Master is tasked with the major challenge to coach the team and those involved with the team, in environments in which Scrum isn’t fully understood and adopted. The team will consistently be confronted by situations where Scrum’s values, events, interactions, and accountabilities are challenged. At times, it will even appear they are impossible or undesirable to uphold. This will result in all sorts of frustrations.
A Scrum Master helps everyone understand it takes commitment, courage and focus — perseverance.
Scrum will stir things up. Conflict will emerge. A Scrum Master might be associated with those tensions. Understand that even Scrum Masters will make concessions out of concern for their job security.
An experienced Scrum Master will talk about this with his team.
Help.
All this is quite something. It can be daunting and very demanding. A Scrum Master will at times feel misunderstood. He or she will not always be taken seriously. A Scrum Master might feel under-appreciated. People might, disrespectfully question the value of the role, for example by questioning if a Scrum Master truly is a full-time commitment. A Scrum Master will likely meet moments of despair.
A Scrum Master too needs help. It’s not easy to uphold the pillars of Transparency, Inspection and Adaptation. It’s daunting to maintain the mirror.
The team and the leadership within the organization can best help the Scrum Master out by supporting and respecting his or her efforts, even when they are controversial at times. Do not judge the Scrum Master on the performance of a team, but on the efforts to help and assist the team to improve. A good way to help the Scrum Master is by running through the responsibilities mentioned in the Scrum Guide together.
Help each other, that is what it is all about.
A final tip to Scrum Masters: nobody likes to have a mother-in-law around pointing out all your flaws. Therefore, lead with positive encouragement.