Scrum Master

Where should I start on this topic. Maybe with the word “Master”. I don’t like it. It denotes a sense of perfection and, well, mastery, over a framework or domain. And while mastery of something is worth striving for, I don’t think anyone really ever reaches that state. There is always something to learn or improve on. Another way to achieve something. There is always another method, yes even within the Scrum framework, that can be learned and applied. But this is of course me taking the word “Master” literally. This is why I prefer the terms Scrum Practitioner, Scrum Coach, or perhaps Scrum Facilitator. Or perhaps I am just being crotchety about the whole naming topic.

But I digress…

What Is A Scrum Masters Focus

There are many podcasts, articles, posts, and twitter threads that speak to the “What does the Scrum Master do all day” topic. Well, allow me to throw in my thoughts.

When coaching, the first thing I want to do is try to establish trust. Most often the team I am going to work with does not know me, but they know one another very well. I usually do this with something like a mind-map of me. And then open up for an ask me anything. And be honest with them.

I take the approach to coaching teams the same if it is Scrum, XP, Lean or Kanban teams. My primary focus is on creating cross-functional, self-organizing teams and instilling a desire to improve as a team in the ways they work collaboratively to achieve their objectives.

I will do this by watching a team work together for a while. Observing and notating where their pain points are from my perspective. This could be anything from organization of the work, prioritization of the work, the work process itself, communication and collaboration amongst the team, ability to resolve impediments, and ability to actually deliver software. But most times I am looking for the relationships and interactions they have. Do they trust one another? Are they empowered to make decisions and solve problems? Does the culture support them working in an agile way?

Now that being said, there are times I have found it beneficial to dive right in and start helping solve some small problem. And that has proven to be extremely beneficial. But back to the previous method…

I will start to share my observations and make suggestions to the team along the way when the time is write. Making an unsolicited suggestion on what you view as a pain point or an area to improve requires delicacy most times. Although, as mentioned, I have been on teams that said from the onset as part of our working agreement that they wanted me to jump in and provide honest feedback and suggestions on things immediately. That was fun!

Now since this is Scrum, I also support the Product Owner. This can be in many different ways, especially if the Product Owner is a first time Product Owner. Helping them to create a transparent view into the Product Backlog and a visual representation of the progress being made in the product. This includes keeping the Product Backlog lean and mean. We don’t want that thing becoming a monstrous dumping ground for “we need to do this someday”. And in some cases I am asked to help with talking through what might drive the most value in the product to help the Product Owner make decisions.

Management tends to be the tough part in most organizations. In the Scrum Master role, I support managements adoption of Scrum with changes to their current processes. Most often though I am focused on the culture they are currently providing and how they can provide a culture that supports Scrum. But to be honest, I am not focused solely on supporting Scrum as much as I am focused on supporting agility and a humane working environment. Scrum can help with that, but just because you run two week Sprints and follow the Scrum events, does not mean you are working in an agile way.

As for the question of “What does a Scrum Master do all day?” Well, that might shock people, but it changes day to day. Honestly, I strive to not have a full calendar all day. Working as a Scrum Master or Coach or whatever you want to call yourself, in this role you need to have flexibility in your schedule to help and coach people. To improve your own knowledge, and provide what you have learned with others. Perhaps a team is struggling with creating “right-sized” stories. Yes Scrum Teams are allowed to use Stories even though Scrum refers to everything as Product Backlog Items. Here is an example of a somewhat normal day for me in the Scrum Master role.

1. Review the latest notes and pain points the team is experiencing and decide how to help them today. This is something I do everyday, but sometimes it is really easy because it can span over time focusing on helping the Scrum Team improve in a specific area.
2. Attend the Daily Scrum. Listen and observe. You do not want to be driving the Daily and turning it into a status report meeting.
3. Opportunities for coaching or conflict resolution may appear in the Daily that might be a point of focus in your day now.
4. If nothing came from the Daily that required your immediate attention, hang out with the team and observe. This is more difficult remote because you would have to all be in a meeting all day with each other. So what I will do from time to time is drop a line to the Product Owner or member of the team on how they are doing. If there is something they need help with etc.., Remote is hard in these situations, but you need to be creative. I went to the extreme and started learning Angular and approaching the team saying “Hey everyone, I started learning Angular and would love to pair with someone or sit it in on a mobbing session and even be the driver building something.” And this went a long way to building trust and getting some insight into what people go through building the software.
5. Look outside the team for opportunities in the organization to improve processes and procedures that negatively impact the teams ability to work in an agile way. Look for opportunities to meet with leadership and coach on agility and the Scrum framework.
6. It is perfectly acceptable and even a bonus for a Scrum Master or Coach to have nothing on their plate to do that day. If you are forever busy in this role, you will miss the reality of what the team is going through, and really wouldn’t be much of a benefit at all. If there is nothing on your plate, start a blog. It helps clear your mind. Engage the Agile community on various topics you are interested in. Get some training on something.

As is customary in most of the posts I have seen like this, people provide a characteristics or traits of a Scrum Master. Ok, I’ll play along.

• Is a great listener. Not just listening to respond, but listening to understand.
• Is disruptive when it is called for. For example, organizational change from silo driven departments to dedicated teams.
• Impediment removal expert when it is called for.
• Coaches the team to become Impediment removal experts. This is awesome when it happens.
• Ensures the team understands and supports the agile values and principles.
• Ensures the team understands and supports the Scrum framework and process.
• Is comfortable with a little healthy conflict within the teams. Even looks for it to be their as a means of honesty and transparency.
• Willingness to discuss and accept new ideas and approaches. Its okay if its not in the Scrum Guide to do something. ie; Pair/Mob/Ensemble Program, Create User Stories.
• Has a competency with XP, Lean, and Kanban.
• Promotes and empowers self management at every opportunity.
• Coaches estimation in Story Points strictly by the modified Fibonacci sequence… WAIT WHAT ?!?! Sorry I couldn’t resist, wanted to make sure you were on your toes and still paying attention.

When you are a Scrum Master or Coach, there are some important questions you can ask yourself that will guide you throughout your days.

• Does the Team work together?
• Are there any conflicts on the Team?
• Is the Team empowered to make decisions?
• Does the Team utilize and value quality?
• Is the Definition of Done appropriate?
• Are there organizational impediments to agility?
• Is the Product Owner managing a healthy relationship with customers and stakeholders?
• Is the Product Owner managing the Product Backlog or is it a dumping ground wish list?
• How old are items in the Product Backlog?
• Are we “right-sizing” work items to be done within 2-3 days?
• Do we generate mountains of technical debt?
• What is the quality of the code?
• Do we consistently ship product?
• Do we consistently ship product with bugs?
• Is our release process painful or so easy the agile coach can do it?
• Are there things within the HR department that don’t permit agility?

This list could go on for a while. But one thing I touched on a bit with a few of those questions should have peeked your brain to think about escaping the Scrum bubble. If you are consistently focused solely on the team, eventually you are going to run up against an organizational impediment to agility. And that is going to be painful to get through. Proactively reach out to other departments and start to talk about the fact that maybe some of the organizational issues are what is preventing agility or Scrum from being as effective as it can be.

For example, if individual performance reviews drive increases and bonuses, people are going to work towards those individual goals, and not focus too much on what is best for the team or product they work with or on. I am not saying people should not be compensated fairly for the work they do. But that shouldn’t be a specific goal that doesn’t align or puts them at odds with the rest of the team.

Example: QA is graded on their ability to find defects and have defect quotas that drives their performance reviews.

Example: Developers are graded on lines of code pushed to production and that drives their performance reviews.

These are not good things and often are at the root cause of why Scrum and any chance at agility could be failing to manifest positive change and results.

Most people do not realize this fact, the Scrum Master or Coach in the organization works across teams and across the organization. In this role, you have a greater insight into how things really work and the impediments an organization has than most executive leadership does. Providing those insights to leadership is, in my experience, the most effective way of making significant change.

As always, I welcome feedback on anything I write.