Scrum Master, Get Over Yourself

Scrum master, get over yourself. That goes for project managers too. You are the least important person on the project, so act accordingly.

I know of what I speak. I’ve been running IT and consulting projects for over 30 years and definitely have been full of myself during my career. Eventually, I realized that while I was “in charge” as a project manager and getting paid high fees as a consultant, I was actually the least valuable and most replaceable person on the project.

Realize Your Lack of Value

I once had a young scrum master working with me on a large IT project. This scrum master was constantly complaining about “IT” not delivering code quickly enough and there being too many bugs. I finally sat them down and made two points:

  1. There is no “IT” and “Business” or us versus them. This is one team, all focused on a common goal. Everyone on a football team either wins or loses together. If the project fails, management isn’t going to sift through the rubble to figure out what went wrong. They are going to simply fire the coach.
  2. And on this football team, you’re the water boy. It is a software project. The only time value is being added is when developer’s fingers are on their keyboards writing code. Value isn’t being added in standups or sprint planning meetings.

Let’s dive into the concept of “value-added” a bit more. The concept of value-added tasks comes from lean manufacturing, and means those tasks that add value to your customers. On a software project the end customers are the users/purchasers of the software. Imagine you gave a customer the choice of buying two identical software packages: Expensive and Cheap. Expensive Software is twice the cost of Cheap Software but had a great scrum master, whereas Cheap Software had a lousy scrum master. Would the customer pay more for Expensive Software? Of course not.

Therefore, the scrum master and their tasks are non-value added. The Japanese lean manufacturing experts would consider them waste, to be studied and eliminated where possible. Hear that scrum master? You’re waste.

Add Value Not Anger

Now before you go crying into your Starbucks latte, lucky for you there is a second customer on software projects. That customer is the sponsor or company management paying for the project. They are willing to pay for a scrum master if they can add value by building the software better, faster and cheaper. Does the sponsor care how well the sprint planning meeting is run? Of course not, the sponsor only cares about results.

So how do you build software better, faster and cheaper? Well, you don’t do it by being full of yourself and being an angry task master. I was at an Agile conference presentation with two young scrum masters sitting in front of me. During the Q&A, one of them raised their hand and asked “If the developers on my project keep missing deadlines or don’t complete all the user stories in a sprint, how do I punish them?”

The speaker was stunned. The speaker eventually answered that the scrum master’s role wasn’t to punish the developers, but to address the process issues that were affecting the developer’s efficiency. The young scrum masters were baffled, they simply asked the question again. They didn’t get it. Don’t be like them.

Can you imagine being a developer with twenty years of experience being called lazy or incompetent by a twenty-something scrum master that has never written a single line of code? Trying to explain the technical issues causing the delay is probably a complete waste of time because the scrum master won’t understand them. If you were the developer, would you be motivated to build software better, faster and cheaper or would you be angry?

Be Supportive

If your job is dependent upon building software better, faster and cheaper you’d better treat the only people actually building the software pretty well. Your role is to support them, not to whip them. And usually, supporting them involves rolling up your sleeves and taking the grunt work off their plate so they can focus on coding. This usually isn’t the type of work a glamorous full-of-themselves scrum master is willing to do. It requires some humility and a willingness to learn. Here are some examples:

  • Help test. Testing is the best way for you to learn the software and to understand technical issues. You’ll also start to learn when a developer truly did screw up on something simple, like a null exception error. Not so you can punish the developer, but so that you can understand if they need additional training.
  • Take on simple administrative tasks. Developers can end up spending a lot of time on administrative tasks, especially to support testing. Many of these are easily learned tasks, that don’t matter if you screw up the first time because it is the test environment.
    • Add testers to the test environment
    • Upload test data to the test environment
    • Edit JSON files or other files for testing
  • Review user stories. Review user stories for quality. Are they complete and easy to understand? Are the acceptance criteria detailed and complete?
  • Off load reporting and configuration. Can you or someone else take on configuration tasks so the developers can actually code? Can someone else write reports?
  • Try to code. Get on the Internet and take some classes on coding using a simple language like HTML or Python. Build a little program/web page and spend hours de-bugging it because it isn’t working. This will give you some appreciation of what developers go through.
  • Buy them lunch. Don’t buy them lunch so that they can eat and work at their desk. Buy them lunch to be nice.

Acknowledge You’re Replaceable

Eventually, you’ll also realize that no one is irreplaceable on a project. As I mentioned earlier, if the project goes south the easiest thing for management to do is to try assigning a new scrum master. If you were a manager trying to get onto the golf course, would you want to stay late to listen to a scrum master explain all the issues that caused the project to fail? No, you’re just going to replace them and hope the new scrum master can fix the issues.

I can speak from experience because I’ve been replaced twice in my career. The first time, I was caught up in a layoff at a large consulting firm. I’ll never forget me marching into my exit interview with a well organized folder of my ongoing activities like sales leads and presentations. The partner didn’t even look at the list. There wasn’t anyone left to pick up my work even if it mattered. I was going to walk out of that office and no one was even going to notice I was gone.

The second time, I was having difficulties getting the product owner and a contractor to stick to the schedule. I made the mistake of escalating the issue rather than dealing with it myself. In the end, they didn’t replace the product owner or contractor, they replaced me for not being able to run my project smoothly. The project ran fine without me.

Over and Out

So get over yourself and become a better scrum master. Be humble: you don’t add value directly to the software and you’re not irreplaceable. Be supportive: do whatever it takes to make the team productive.

If you get over yourself, you’ll get your project over the finish line. And, the project sponsors will be over the moon.

    Leave a Comment

    Your email address will not be published. Required fields are marked *