Scrum Master behaviours — don’t mask the problem
I had a conversation recently that reminded me of an interesting lesson I learned as a Scrum Master some years ago, and I thought it might be helpful to share.
The situation
I was working on a project that was important, really important — it’s probably the most important project I’ll ever work on. I’m making this point so that you can understand my mindset at the time.
Some people on the team were independent contractors, some were permanent members of staff and many others were from a third party supplier. In my mind though that was unimportant (and it still is), we were there for the project and to ensure that it was a success. As such I was willing to do whatever was required to make it a success, as far as I was able to.
While I was there another Scrum Master was brought in to run a couple of the other teams. Lovely person, really keen, very enthusiastic. But it turned out that while they knew the mechanics of Scrum (the ceremonies, roles, artefacts etc) they fundamentally just didn’t “get it”. By this I mean they would go through the motions without understanding why they were doing them, or more specifically what each part played in the overall scheme of things (this is one of the basics that I refer to here).
The problem
I was still very much focused on the project and ensuring that everything that needed to be done was being done. So without any real thought I would go over some of the things that the other Scrum Master was (or wasn’t) doing and fill in the gaps — because they needed to be filled in — if I hadn’t done then the project would have suffered. And so things went on for quite some time, until a realisation dawned on me:
The problem here, was me.
Specifically I was not performing an important function of my role, and that is to highlight problem areas within the process that are inhibiting it’s proper function, instead I was masking the problem. While my intentions were good (putting the project first) I was failing to bring to light the issue of someone who just wasn’t understanding what was required of them, and their teams were suffering as a result.
The subtleties of being a Scrum Master
Not everything is covered in the Scrum Master certification training, and some fairly big assumptions are stated (for example the kind of people you would have in your team, theory-x people vs theory-y). Some things (most?) you only learn with experience.
As a Scrum Master one of the (many) responsibilities is to raise issues to those who can help resolve them. It’s vital to state here that you don’t want to be one of those people who just complains (no one appreciates that), but it is fine to raise concerns along with options as to how the situation can be resolved. That always goes down well because it shows you understand the situation and what the effects of different outcomes are.
As I Scrum Master I failed here (for a long time) to properly raise the issue of another resource who was failing to deliver in their role, which is clearly a situation that needs to be resolved. I had good intentions by helping to cover the gaps in their work (and I did spend many hours trying to coach them and explain the what / whys and hows of the role). In the short term what I did probably was helpful, but a year later the situation was exactly the same.
Another example
I worked with another Scrum team that had recently brought in automation testers, which was obviously fantastic as automated testing is pivotal in order to be making regular quality releases into production. They defined the frameworks and set about covering the backlog of tests that were missing, and then started in with the normal sprint based work of testing new stories.
The thing was that they seemed to struggle with understanding the testing scope / impact of a story unless it was clearly laid out for them, piece by piece. I used to be a developer so I would help with this, making sure that during backlog refinement everyone was clear on what is involved so that they can estimate the story (since people can’t estimate something they don’t understand).
I had a conversation with my Product Manager (different organisations can have different roles sometimes) where I explained that we had an issue because if I wasn’t there then the testing wouldn’t be understood, and the sprints would subsequently fail. Their response was that I was there so it was fine, which makes sense from their point of view, but it masks the fact that the testers are having problems understanding the complexities / impact of the work that is in front of them.
NOTE. I feel this is a point with some subtle nuances. This one may seem slightly unreasonable on my part, I was in the meeting so why shouldn’t I contribute to the teams success? I’ve always felt that a Scrum Master should be totally replaceable, in fact their job (in one respect) is to make themselves redundant, as they should be coaching their teams to take on all the day-to-day mechanics of delivering software without needing someone to guide them (although in fairness I haven’t seen many teams who actually function like that). It is definitely the job of the Scrum Master to make sure that the backlog refinement meeting happens, that a room is booked, the team know when and where it is and what they are supposed to cover. But if a room full of technical resources are needing input from a Scrum Master on technical matters then I think that is a problem with the team that needs to be addressed — continuing (long term) to chip in and help is only masking a very serious issue.
In this example the team could fail if I went on holiday — due to misunderstood stories, and subsequently a failed sprint (as I described in detail in this post). That clearly is a big problem and something that needs to be resolved.
Summary
This is just one area where a Scrum Master needs to really understand the exact nature of their role. Yes, it is a (very) wide ranging job description, and you will end up doing all sorts of weird and wonderful things, it’s what you sign up for. But sometimes issues do need raising and that is very much part of the role. You can’t just become someone who complains constantly or says “that’s not my role” (even if that is the case), you need to present solutions to the problems.
It takes time and effort to find the right balance between being helpful / too helpful / raising concerns / blatantly obstinate (and yes, sometimes there is a place for all of them). A Scrum Master is there for the project, but masking issues will only hurt the project in the long term.
