Leave a comment

Are you a failing Scrum Master?

I have number of concerns with the typical view of what an effective Scrum Master looks like. This post is designed to evaluate how successful a Scrum Master is when there is more than one Scrum team, other types of teams and management involved in a project.

Take a look at a number of articles around the web and you’ll find questions like these (a small subset) associated with being a successful Scrum Master:

  • Am I tracking and dealing with impediments?
  • Is my product backlog being managed?
  • Is my team clear on the sprint goal?
  • Do my team feel accountable to each other?
  • Does the team get on well?
  • Is a suitable amount of inter team communication happening?

There is nothing wrong with these types of questions however I believe they aren’t sufficient when assessing performance within a multi-team set up. I’ll start with a simplified section describing a typical Scrum Master who is working well with their own Scrum team. From there we’ll consider additional factors to see how well the Scrum Master is working within a larger project context, and generate some new questions to help judge their successfulness. I’ve put all of these new questions together at the end of the post in case you wish to copy them.

The Scrum Master working well for their team

Most Scrum Masters are good facilitators, they help the Scrum team tune their processes, resolve conflict and encourage co-operation. They can help their team externally by raising their impediments and attending external meetings to discuss their teams progress and concerns. Scrum teams, like any other type of team, typically go through a cycle of forming, storming, norming and performing (Bruce Tuckman 1965). They do this at a reasonably fast pace because they’re all working together on a common goal each sprint and have a lot of face to face communication to achieve it (assuming they are co-located). The Scrum Master can help ensure this transition is as smooth as possible by being a mediator when conflict arises and looking out for unconstructive arguments happening between team members.

There are other parts to the Scrum Master role I could delve into, however there is little disagreement about what makes a good Scrum Master when representing their own team. Let’s look at how the Scrum Master can cause a multi-team project to fail despite being effective at a team level…

The Scrum Master at the project level

In this section I’m going to focus on how a Scrum Master can be judged for effectiveness across a multi-team project. If you are a Scrum Master consider using the questions here for self reflection, or run a session with others on your project to help you all improve.

Forming, storming, norming, performing across teams

Following Bruce Tuckman’s model that we’ve already looked at, Scrum team members may actually stay in a state of storming with external teams all the way through the project. Direct conflict may not be occurring but replaced with complaining and finger pointing behind the scenes. As a Scrum Master you may be one of the few people to see this and do something about it. You can facilitate improved co-operation and better outcomes. These types of behaviors are really bad if you are a Scrum Master and doing this yourself, as there may be no one to stop it. It can be tempting to automatically take your teams side when presented with conflict too, and although this builds up your own team, it can destroy trust and damage the wider project.

  • Do I actively monitor and resolve conflict between my own and external people?
  • Do I tend to take my own teams side when there is an inter team or management conflict?

Process conflict

If you are involved in an argument about a process that actually results in the same output, then why are you arguing? This is typical of a “best practice” mentality where only one way of doing things is seen as valid (typically your own). Concentrate on the quality of the outputs rather than the processes used to create them. An example I have seen of this was where an argument kicked off around how to run the sprint planning meeting, with one Scrum Master insisting on story tasks for each story and another insisting they are a waste of time. I’m not going to cover the pros and cons here, but both teams were producing good outputs using their chosen process.

  • Do I appreciate that in some cases different internal team processes can produce the same outputs when seeking to resolve conflict?

Management

In some people’s view they would see management as unnecessary, I do not ascribe to this. Although you can argue this point, if you are in a role where you are reporting into a manager then this section is relevant. You cannot simply get rid of that person(s). Typically managers who sit across Scrum teams perform a role with responsibilities like these:

  • To formulate and share the big picture.
  • To be a central point for reporting project progress.
  • To facilitate the making of key decisions and sometimes make a call where consensus cannot be reached.
  • Represent the project teams as the primary point of contact for outside structures.
  • Help remove organisational impediments.

I have seen behaviors where individuals at the Scrum team level seek to take control of a project and cut management out. This causes major issues for the project, where management start to see unexpected impact from hidden decisions that can conflict with the big picture strategy they have in place. The manager who is representing the team is then not reporting accurately, ultimately undermining the project by losing control of the big picture. At a minimum it is courteous to involve a manager in a potential decision that affects the whole project. Ideally a clear justification for a change should be made too, so everyone is lined up with why a change is needed. There may be good reasons you don’t know about for previous decisions being made.

  • Do I fully understand the role of my manager(s) and how it relates to the rest of the organisation?
  • Do I understand that the management team are part of my team and are there to direct the big picture?
  • Do I involve management in any project wide changes that my team or I wish to make?

Scrum of Scrums

Here are Mike Cohen’s questions (link below):

  • What has your team done since we last met?
  • What will your team do before we meet again?
  • Is anything slowing your team down or getting in their way?
  • Are you about to put something in another team’s way?

Link accessed 26/09/2015:

https://www.scrumalliance.org/community/articles/2007/may/advice-on-conducting-the-scrum-of-scrums-meeting

I’m actually going to critique these questions as I personally don’t agree with them. See what you think about my argument. When listening to others people’s answers, except for the fourth question do you even care about this information?! With a team focus it is easy to ignore the answers. Take the first and second questions, is a detailed update on task level information for each story useful? Is progress for each story useful? As a more important question, do you really care what another team is doing? Taking the third question, are you bothered about what is slowing another team down if it doesn’t affect you? In the final question consider moving this to sprint planning, which is a great place to assess impacts, and wouldn’t result in late impact notifications. Think about inviting a member of another Scrum team along for them to see if they are about to get impacted. Your team may have a poor understanding of what the other teams have been doing and have no idea that they are about to break some new work that another team are going to do. Now I will recommend a different set of questions:

  • What is your team delivering to another team (name them) and when will it be ready?
    • Example: My team are working on moving the new test data into your environments this will affect everyone and it’ll arrive on Friday.
  • What is slowing down your team or getting in their way that you expect someone else here to help you with (name them)?
    • Example: My team is finding the current application server too slow and need help from Bob.
  • What is your team going to do that you expect to break someone else’s work (name them)?
    • Example: My team is going to change a person titles table name, it will break all the related tests.
  • My team is currently on / off target to achieve their sprint goal and I intend to fix this by (if off)?
    • Example: We are off target to deliver, as the new computers aren’t here yet, I am talking to Phil about this today.

Except for the last question this is far focused on resolving inter-team dependencies. It means I am making statements that people care about rather than random status updates. Look for long running items that need to be planned in or solved as a group. Many of these questions can result in long term concerns being raised.

  • Do your team impact another teams without sufficient warning?
  • Are you being impacted by other teams without sufficient warning?

Long term technical debt

The problem I’ve seen here is that teams will often create ways of avoiding dependencies rather than actively solving them. Creating two versions of tables, two sets of tests and only running their own etc. We can actually cheat these dependencies by storing up technical debt that will have a major impact on the project later on. As a Scrum Master you need to be looking out for these issues. If there are dependency failures then you should look to facilitate better ways of working rather than workarounds.

  • Is your team building up technical debt to avoid inter-team dependencies?

Scrum Master to Scrum Master relationships

In this case we are looking for silo focused behaviors caused by the Scrum Masters definition of success being their own team’s progress, rather than success being viewed at a project level. A pure focus on team success leads to Scrum Masters ignoring the other teams unless they are directly impacted by them. If they are impacted this typically results in annoyance and a blame culture ensues. Look out for a lot of issues being escalated to management when this is happening.

  • Are my relationships with other Scrum Masters positive, collaborative and ultimately successful?

The big picture view

Here we see the Scrum Master helping to facilitate project understanding among their team. They may prompt management for more information if they are not getting it. A failure to understand long term project goals, timescales and project inter-dependencies can lead to teams running blind and making poor and expensive decisions like overbuilding areas of a system at great cost.

  • Do my team and I understand the whole project, its timescales, major milestones, goals and how we fit within it?

Retrospectives and change

Retrospectives will highlight where something is not working well. That is fine until we try and make changes locally that affect everyone else. Scrum Masters should pay careful attention to wider team impacts from retrospective items. A team who dislike how testing is done should not simply change the way they test. These action items should be moved to a cross team discussion. They are still valid but changes must be made with the other teams in agreement or the project will break. Management should also be invited to these sessions to understand the impact. Changes may occur outside of the retrospective meeting but the same principle applies.

  • Do I ensure that when my team wants to make a change that affects everyone it must be agreed with everyone?

In summary

These are the questions I’m adding to the Scrum Master role:

  • Do I actively monitor and resolve conflict between my own team members and external people?
  • Do I tend to take my own teams side when there is an inter team or management conflict?
  • Do I appreciate that in some cases different internal team processes can produce the same outputs when seeking to resolve conflict?
  • Do I fully understand the role of my manager(s) and how it relates to the rest of the organisation?
  • Do I understand that the management team are part of my team and are there to direct the big picture?
  • Do I involve management in any project wide changes that my team or I wish to make?
  • Do your team impact another teams without sufficient warning?
  • Are you being impacted by other teams without sufficient warning?
  • Is your team building up technical debt to avoid inter-team dependencies?
  • Are my relationships with other Scrum Masters positive, collaborative and ultimately successful?
  • Do my team and I understand the whole project, its timescales, major milestones, goals and how we fit within it?
  • Do I ensure that when my team wants to make a change that affects everyone it must be agreed with everyone?

I’m sure there are more you can come up with and I’d be interested in knowing if you agree.

I’m sure there are more you can come up with and I’d be interested in knowing if you agree.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: