Notes from a conversation with a scrum master

Back before 2010, I worked in a call centre as a team manager. I hated it. The biggest reason I hated it was because I wanted to change things for the better, but my job was not to do this. My job was to keep everything in the operation ticking over in the same state.

So I left as soon as I could.

I found myself working instead as a business analyst, which is a fancy way of saying I worked on IT projects. I did this for nearly five years, for several big companies. I kept on working in this type of role until two years ago, when I joined my current employer.

At that time, I started working alongside an agile software development team who were using scrum as their main way of working. A lot’s been written about scrum; essentially it’s a framework for IT teams that prioritises working software, responding to change and close collaboration between team members. When I began working closely with this team, I fulfilled several roles — firstly and most importantly, designing customer journeys, interviewing customer for research and then documenting designs and requirements. However, from the perspective of a scrum purist I sort-of also became something called a “scrum master” (I didn’t make this term up; it’s part of the official terminology of the “scrum alliance”, the official custodians of all things scrum.) What changed? In simple terms, a designer is responsible for how a piece of software will look and behave (usually pictures, clickable prototypes or a big long list of all the things a new system must be and do). By contrast, a scrum master is a facilitator - a coach and a subject matter expert in agile and scrum development methods.

This year, our company has hired a new chief technology officer. He expects all teams to work at a high standard. In this situation I knew I’d need to up my game. I decided to canvas local scrum masters within the Manchester area, and ask them for advice on how to be the best at this role it’s possible to be.

Glenn Chapman knows exactly how to be an effective scrum master. He’s done this role for several years, for several teams at the same time. By sheer coincidence, we probably were in the same building at the same time some time in 2012, because Glenn works for Bupa and I did too. Glenn works at the Staines office; I did not but I used to fly down a few days a month for a time in 2012 because I was working with a team in that office. It’s coincidences like this that make you realise how small the world is sometimes.

I spoke to Glenn on the phone earlier this month and he was able to answer a lot of my questions about being a scrum master. He went to great lengths to answer my questions as thoroughly as he could, for which I’m extremely grateful. I have nothing but appreciation for his methods and willingness to help someone who’s basically a complete stranger. I hope I can repay him one day, but as Glenn himself said during our chat, the best thing to do sometimes is simply to ‘pay it forward’ and help someone else.

The following are the top lessons about the scrum master role that I learned through my conversation with Glenn. The wording is my best effort to reproduce what Glenn said; any errors or objections caused by this wording are my fault, not his:

1. If the scrum master role is done well, there is more than enough work to occupy you for the entire two-week duration of a sprint. It is common for scrum masters, especially when they’re new to the role, to experience peaks and troughs in the amount of activity they need to complete throughout a two-week sprint. However, a more experienced scrum master will find ways to ‘smooth out’ these quiet and busy days, for themselves and others: for instance, by arranging backlog grooming with the product owner as soon as the team has started working on the sprint backlog; or by encouraging QAs to work closely with Developers as soon as they start working on tickets. “There is a slight dip after a couple of days”, says Glenn. “But what I like to do is make sure that the Developers and Testers are going off and working on things together.” Glenn also refers me to a very comprehensive checklist of tasks a scrum master can and should be doing throughout the two-week sprint — which is very large; he tells me that if I can get everything on the checklist done inside a sprint, then “I’d like to know why and how, because you’re doing a lot better than some.”
2. A combination of group and one-to-one coaching proves more effective than coaching the whole team alone. “I’d recommend that you get around to everyone once in a while”, Glenn advises. “It depends on the frequency you’re after, and whether you’re just looking to catch up or to discuss things more in detail”. According to Glenn, it’s important to ‘check in’ with all team members regularly, and provide them with space and opportunities to give feedback. “They need to know that you have an open-door policy”, he says, “so they feel they can come up to you at any time and ask you about anything they have a concern over”. This is especially important when a team is new and lacks confidence with scrum, but it’s a good idea to maintain this level of contact even after the team’s understanding of scrum has matured.
3. A scrum master should always be actively seeking opportunities to coach the team. If, for instance, a team member is new to scrum and becomes blocked on a particular ticket, in their willingness to help progress the team’s work, they may simply start a new ticket instead of checking with anyone else first. As scrum master, if you become aware that this has happened, it is your responsibility to coach this team member. They need to understand why starting a new work item was the wrong approach, and it would have been better to focus on unblocking the current one. “When a team member is new to scrum, they will sometimes become concerned if they become blocked on a ticket”, Glenn says. “That’s where you can end up with people working on multiple cards simultaneously”. That’s the point when you have to pull them to one side and explain to them why it’s better to focus on unblocking a single thing, than to have four things in flight, with none of them ever getting finished. Unless they are always on the lookout and keeping abreast of what everyone’s doing, the scrum master may miss such opportunities to take the necessary corrective action, and small mistakes can become large and significantly more expensive errors later on.
4. It is better to adopt a more open coaching style, than to be directive and simply tell people what to do all the time. “I’m not a very directive person”, Glenn told me, “so I will always say to a team member: ‘have you thought about this?’ instead of ‘do this’ or ‘do that”. Doing the former, will foster independence and a greater level of personal awareness amongst the team members. By contrast, taking a hard line and ordering people about will have the opposite effect: team members will stop making any effort to think for themselves. Instead, they will become incapable — or at least, unwilling — to devise any solutions without you. This condition is referred to as a “learned state of helplessness”, and is the exact opposite of the kind of team dynamic a scrum master should be seeking to create. “People can just start thinking — ‘well you’re going to start making the decisions for me all the time’”, describes Glenn when explaining this concept. You may need to be slightly more directive when a team is first formed or if they aren’t familiar with scrum; but very quickly they should gain the knowledge and ability to create their own solutions. Once this occurs, it is far better to hand responsibility back to the team than to carry on providing all the answers. A popular technique for shifting responsibility back to the team is reflecting questions back onto the person who asked them: one example that Glenn offers of doing this is asking: “‘What do you think you should do?’”
5. The scrum master will provide the team with different kinds of value at different points in their life-cycle, depending on their level of ability, knowledge and confidence with scrum. For instance, in the team’s early days the scrum master will usually have to coach and instruct the team in how to perform each of the scrum “rituals”, including retrospectives, sprint planning and sprint demonstrations. The team will receive the most value from your efforts through the internalisation of these core scrum practices as habits. But this will change. “If they’re asking for your help then clearly that’s a good sign”, Glenn concedes. “But through time, as the team gets better and better, that’s when you should spend your time instead focusing on improvements; thinking about how you can improve your processes”. What sort of processes? According to Glenn, unit test-driven development; automated integration test; and other ways to automate deployment are key priorities for a scrum master. So, once the team have internalised the scrum rituals, the scrum master should shift their focus to the things that may not provide as much value to the team, but are still highly beneficial. “I highly recommend you use automation wherever you can in the sprint”, says Glenn; “the more you use all of that, the more effective the team will become”. These secondary benefits may include the sort of technical refinements already mentioned, or alternatively, just finding ways to increase the team’s overall happiness and productivity.
6. A lack of technical experience or background as a developer is not a disadvantage to someone wishing to act as a scrum master. As Glenn puts it: “Don’t forget that the scrum master role is about coaching teams to become more agile — not coaching teams how to code”. The developers themselves can — and should — be taking responsibility to coach and up-skill each other in development practices. If you still lack confidence when discussing technical topics, there are still ways for you to address that. Here’s Glenn again: “Simply reading management briefings regarding a certain technology or application is usually sufficient to provide you with the knowledge needed to discuss something with the team”.
7. One of the biggest challenges faced by the scrum master is from outside the team, not within. Often, changing priorities and demands from the team’s various business customers will threaten to disrupt their effective working practices and their frequent, reliable delivery of working software. For example — what is the biggest challenge faced by Glenn and his team? “For us, it’s people changing their minds outside of the sprint”. Glenn, and all scrum masters in general, are responsible for protecting the team members from this outside influence: acting as a guard and protector from disruption; unclear or changing requests and any other unwelcome outside influences.
8. The scrum master will often have to coach other stakeholders, not just members of the scrum team. Very often product owners, senior stakeholders and other people who aren’t part of the team will need just as much coaching on agile and scrum processes, and it will fall to the scrum master to take responsibility for this and act as the business champion of agile and scrum. “Sometimes you can have personality clashes with people, and you have to try and put those to one side”, says Glenn. “This can be difficult when you’re working with a new product owner who knows the business but doesn’t understand how to shape user stories or make sure they’re appropriately sized”. As Glenn has found, in these situations it’s up to the scrum master to coach the individual in how to properly perform the duties of product owner.
9. A scrum master can act in this capacity for between one to four teams simultaneously. Of course the quantity and quality of support they can provide each team is proportional to the number of teams they are supporting at once. If a team is newly-formed, or some of its team members are new to scrum, the scrum master may recommend that they just coach that single team, at least for a short period until scrum processes become internalised and habitual. Once this learning has been cemented, and the team can operate with less support, you can expand your scope to include other teams and still ensure that every team gets as much support as they need. “Currently, I have three teams”, says Glenn. I have to ask: what is the most teams he’s ever supported at once? “At one point, I had four teams”, he concedes, “but it was too much”.
10. A scrum master can maintain multiple scrum teams who all operate the same sprint ‘cadence’ — although to do this they must use their time very efficiently. If a scrum master supports multiple scrums, and they all have the same “sprint cadence” — meaning that they all start and end on the same dates — this can make certain days particularly difficult for a scrum master. Each scrum needs to hold their sprint planning session on the sprint’s first day, and if this is delayed it means the team can’t start work. This can be overcome by taking an organised approach; Glenn, for example, holds three separate sprint planning meetings on day one of each two-week sprint. He arranges these to occur almost back-to-back, so that they all fit into a single working day despite each lasting several hours apiece. This means that all scrums get to hold their planning meeting one the first day of the new sprint. Because one of his scrums contains several team-members working off-shore, he holds their scrum’s planning session first. This compensates for the time difference between him and his team members: India is roughly four hours ahead of the UK.
11. It’s the duty of the scrum master to ensure all feedback and suggestions are captured during every retrospective, and that these are then followed during subsequent sprints. If a scrum master supports more than one scrum, this can become a substantial commitment. For this reason, some scrum masters will often enlist their team members to assist with this, for example by delegating certain actions to the individuals who suggested them. This also helps to foster an atmosphere of responsibility amongst the group: after all, it is their meeting, not that of the scrum master.
12. An effective scrum master will use various techniques to elicit active participation from all team members during retrospectives. These include priming team members a day or few hours before the meeting, reminding them that they need to bring feedback and suggestions to the meeting; asking open questions during the session, so that everyone feels they are permitted to answer; leaving long silences between discussion points so that people feel uncomfortable and thus are compelled to fill the silence themselves; and finally, frequently switching up the format of the retrospectives so that it remains engaging for the participants.
13. Feedback in a scrum team is most effective when it’s given shortly after the event that caused it. This means that feedback doesn’t have to wait for the fortnightly retrospective before it can be given; a good scrum master will regularly seek feedback from their scrums, and frequently grant people the permission and space to make their feelings and opinions heard. The daily stand-up is a good natural space within which to elicit and capture such timely feedback, as the events of the previous day will usually still be fresh in people’s minds. However, this frequent feedback should never act as a replacement or substitute for the retrospective at the end of each sprint: the retrospective is a crucial part of scrum, and it is the primary means by which each scrum should seek to capture feedback and improvement actions. The scrum master can facilitate this in part, by capturing any daily feedback from the daily stand-ups, and then reviewing it all at the start of the retrospective so that all daily feedback is incorporated.
14. There are many advantages to using electronic backlog management systems over just a physical board and cards — although either can be effective depending on the team’s circumstances. Such systems — examples of which include Microsoft’s Team Server or Atlassian’s Jira — are useful for several reasons. Firstly, they allow any team members located at a different site to view exactly the same information as people at the head office. Secondly, they allow a scrum master to produce key sprint reports such as burn-down charts or cumulative flow diagrams at the click of a mouse. However, there are also advantages to using simple physical boards and cards instead; these include the tactile satisfaction for team members of moving a card across the board, and the accessibility of the data to passers-by. The scrum master should ensure that the team agrees upon an approach that is right for them; ultimately it is their decision. Some teams will use a combination of both, ensuring that they keep the physical board and electronic counterpart in sync. This is also acceptable.
15. Scrum and kanban are not directly comparable — therefore, a scrum team can choose to use either one, or both simultaneously. “Scrum is a process, whereas kanban is a process improvement method”, says Glenn. Because they are not directly comparable, it means that choosing to use one does not automatically prevent you from using the other. They also measure entirely different things: scrum primarily measures a team’s velocity in terms of story point completed in each sprint, whereas kanban measures the average time taken for each work item to pass completely through the process, known as “cycle time”. The time taken on average for work to pass through each individual stage can also be measured for increased accuracy. The use in kanban of “work in progress limits” (i.e. limiting the number of work items that can occupy a certain stage column) also means that blockages become visible very quickly. Both have benefits, and opinion is clearly divided within the industry around which is preferable. “A lot of people think if you’re new to agile you should start on scrum”, says Glenn, “whereas kanban is the next step up from your existing process. With kanban you can start looking for bottlenecks in your process, and focusing on finishing work before you drag in new items”. What do I think? Both methods have appeal; both use profoundly different mechanisms to encourage speed and productivity. The momentum for a team using scrum primarily comes from their collective accountability for the commitment made at the start of each sprint. By contrast, the momentum for a team using kanban primarily comes from the use of work in progress limits and the fact that bottlenecks can be identified and thus eliminated very quickly. Both have advantages; therefore the scrum master should ensure that each scrum decides for themselves whether to use scrum, kanban or a combination of both.
16. It is advisable for a scrum master to capture several different types of measurement data to constantly evaluate the team’s performance and whether it is improving. The two most common types of measurement are velocity, which is used by scrum teams, and cycle time, which is used in kanban. For a team using kanban, the scrum master can take even more detailed measurements by keeping a record of the date that every work item moves from each column to the next. This allows them over time to calculate the average time that work items spend in each stage of the development process — exposing bottlenecks and other deficiencies in the process. Due to the lack of capability of any of the most popular electronic management systems to track this detailed view, it may be necessary for the scrum master to record all this data manually themselves, using an Excel spreadsheet. However, many would argue, including Glenn Chapman, that the quality and value of the information gathered in helping a team to track and improve its efficiency far outweighs the cost.
17. If someone aspires to obtain a permanent role as a scrum master, the best ways to do this are firstly to take the Certified scrum master qualification; and secondly, to demonstrate that they can perform the role well by managing their current scrum teams effectively. The scrum master certification, admittedly, is specified by recruiters on a lot of job adverts. “That is still what a lot of employers are looking for”, says Glenn. And how can someone prove their current capability? An excellent scrum master will be constantly be demonstrating the following key capabilities: coaching individuals to increase their skills, knowledge and capabilities; facilitating scrum rituals; teaching groups about scrum and agile; mentoring junior team members and/or less experienced product owners or other stakeholders who lack experience of scrum; knowledge of scrum and agile; technical knowledge; business and domain-specific knowledge; and finally skill in facilitating organisational change and transformation. In addition to all this, one of the most important things that a scrum master can and should do, is to ensure that all of their scrums constantly have access to a product backlog that is comprehensive; that is continually being groomed and elaborated upon; whose work items have sufficient clarity and distinctiveness from one another; and those work items have been relatively sized against one another by the scrum that will be delivering them. If all this consistently remains in place, then the individual will have shown themselves to be an extremely confident and capable scrum master.

My conversation with Glenn took just thirty minutes, but in that time I feel as though my knowledge of the scrum master role and what it involves has gone through the roof. I can only thank him again and hope that I can repay him some day. In the meantime, I will absorb the lessons from our conversation into my daily practice, and I’m sure both me and my teams will benefit as a result.