Scrum Master Wanted: Competence Not Required?

A recent thread at Workplace Stack Exchange about managing developers who are more talented than you contains a comment that neatly sums up how to lead subject matter experts:

You don’t even need to be competent, as long as you listen to competent developers and don’t claim to know better.

I have written previously about being careful not to get stuck in your previous mentality as an individual technical contributor. Technical skill is often one of the factors considered when deciding whom to appoint as a team lead, and it is tempting to act like your leadership in scrum is still based on technical merit. But what happens when you’re assigned to lead people who are much, much better at something than you are (like at my current job)?

In scrum, this is a non-issue. The Scrum Guide clearly says,

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality

Their skill level in relation to yours is completely irrelevant. A large part of your job is to foster a work environment where the development team can do their best work. You do this by listening to the developers’ needs and then working to remove any obstacle that keeps those needs from being met. Your ability to do that is not principally determined by your knowledge of object-oriented programming or web services.

Does that mean that a scrum master is not allowed to talk shop with the developers? Not at all. But if you’re going to talk with them in technical terms, and the developers really are in a different league than you in terms of skill, then you need to realize that almost any technical conversation you have with them will be for your own benefit more than theirs. One could argue that you are wasting their time by doing so. Be appreciative when they take a few minutes to explain something to you.

It is always helpful for a leader to have some understanding of the work done by those he leads. It increases your empathy with them, which helps you understand their challenges and what needs to be done to resolve them. But being good at what the developers do is not required (maybe it’s not even a significant plus) as a scrum master. I continue to be humbled in my job as I keep realizing how little my technical background actually matters. As we more deeply internalize the fact that our job is to help others do their job, any arrogance or intimidation we feel from comparing our technical skills with theirs will be replaced by the security that we are providing far more value to the organization by making their job easier than by trying to do it ourselves.

A Scrum Master in Hand is Worth Several Other Roles in the Bush

Conventional wisdom says that a scrum master should not also be a product owner because the inherent tension between the two roles leads to a conflict of interest. Being a scrum master and a developer at the same time is at least implicitly acceptable, as the Scrum Guide says that scrum masters are not included in the development team’s head count “unless they are also executing the work of the Sprint Backlog.” Being a scrum master and a traditional project manager at the same time seems to be somewhat common in organizations that still have one foot in waterfall, and Sally Bommen has an article at ProjectManagement.com where she shares her experience in that dual role. But a scrum master that develops, owns, and manages?

I have written previously about how my technical background has been both an asset and an obstacle to being an effective scrum master. I tried to keep both my developer hat and my scrum master hat on. Since not all of our applications have a dedicated product owner in the business, I was asked to take on that role as well. And since our organization is still fairly waterfallish, I get to produce slide decks and charts like a traditional project manager. (Oh, and most of the data that feed the charts come from a data mart that I implemented. Dev hat.)

I don’t resent being in this multifaceted position. It’s educational and mostly fun to wear all the different hats. But it does have real drawbacks. As a jack-of-all-trades, you don’t have the time to really master any one of those roles, and it’s difficult to really understand the history and future of any of the applications you semi-own. You end up fulfilling all those roles well enough to keep the fires under control, but you’re not a rock star at any of them, and it is difficult to drive real improvement in any one area. Maybe even worse than that, carrying such a combination of roles also leaves the team unclear as to which methodology they should be following. It is easy to have friction if, for example, you tell the team to be self-organizing but you keep trying to direct the work. And anything that hurts team cohesion needs to be fixed quickly to keep avoid hurting the products’ quality.

I’m not providing any real new insight here, just reaffirming that trying to do too much leads to less-than-stellar performance in any of those areas. A scrum master in hand is worth a development team/PO/PM in the bush. Worth how much? That’s for you and your organization to decide. But resist the temptation to give one person, perhaps yourself, too many hats. It’s not a good look for you, and it’s not the best way to grow an agile culture.

Don’t Let Your Technical Background Hurt You as a Scrum Master

It took me over a year after I became a scrum master to learn to stop making technical decisions. (I still do it sometimes.) This is a common pitfall for former individual contributors who are placed in a leadership position: they focus too much on what they used to do as individual contributors, and not enough on the big picture. It’s natural — that’s what you spent years doing and perfecting, and what you feel most comfortable with — but that doesn’t mean it’s right. Especially in a framework like scrum, where the team members’ roles are specifically designed to keep them from overstepping their bounds with one another.

One of the teams I worked with had a project that involved a lot of Python. Despite my having only a few months of experience in that programming language, it was still more than the rest of the team had and I was excited at being able to contribute my knowledge. I pushed for coding standards, participated in code reviews, discussed how the documentation should look, debated the use of third-party modules, encouraged the use of Git over SVN, and tried to understand in detail what the developers were working on. I felt proud of myself for providing some of the technical leadership on the project.

Then one day, an issue I had raised in a code review was rejected.  Had I been more familiar with the code, I wouldn’t have incorrectly pointed out what was really not an issue at all. Then it happened again. I found myself flip-flopping on dependency management because I didn’t fully understand the ecosystem the library would be used in. I started asking more “how” and “why” questions. There began to be some friction between the senior developer and me. My technical advice soon began reaching its limit, even though there was plenty of work left to do on the project. I started to get self-conscious and wondered if I was making a fool out of myself. (The team was nice enough not to say so directly, but I’m sure I did.)

My technical participation did have some benefits, but I insisted on continuing to do it even when it should have been clear that there were diminishing returns. I was not adequately fulfilling my role as a scrum master because, even though I was helping the team to create a high-value product, I was telling them how they should do it instead of letting them self-organize and decide on their own. And even worse, I did not have the necessary knowledge to continue providing useful guidance more than a few months into the project. A better way to help the team would have been to organize an overview of some practices I thought would be valuable and then let them decide if/how they wanted to adopt them, rather than practically dictating how they should do things. This would have allowed them to be more self-organizing, and possibly increased their sense of ownership and accountability for their work. I’m sure you can think of other ways that I could have handled those interactions better.

A lot of scrum masters come from a development background. They bring knowledge and experience that can help their teams produce high-value software. But as scrum masters, we need to remember that our role is not one of technical leadership, but of servant-leadership. Our mindset must shift from helping the team to helping them help themselves. Keeping this in mind and acting accordingly with our teams will help them do better work and foster a better working relationship with them, as we “respect each other to be capable, independent people.”

Protecting Your Team Does Not Mean Protectionism

Protectionism is the economic practice of protecting domestic production and trade by making it more difficult or expensive to trade with other countries. It is also manifest in office politics when one team or department refuses to work with another because they’re afraid of losing control over their own little kingdom. Whatever the pros and cons of protectionism are at a macroeconomic level, it is almost always a bad idea in the workplace because it keeps you from building bridges with other communities within the company and isolates you from individuals with skills that can enrich your team. Enriching your team = higher quality of work = higher likelihood of success.

When I became the scrum master in one particular team, someone from the customer’s team was pushing to have one of their developers join us remotely. I wasn’t happy about it; not because I had anything against that developer (I hardly knew him), but I felt that the person who was pushing for it was overstepping his bounds and I wanted our co-located team to gel before adding another variable to the work. In the interest of good relations and giving that person the benefit of the doubt, I grudgingly agreed to have the remote developer join our team but kept him at arm’s length for a few sprints.

That was an immature mistake. The remote developer became a valuable member of our team and helped us identify issues in code that he wasn’t even working on. He was originally focused on QA tasks but made himself available to help with coding, which we needed more of, and having him on the team helped us learn more about the QA side of things through osmosis. Having him on the team also enriched our retrospectives as we looked for ways to use his role in our continuous improvement efforts. All in all, the benefits outweighed the logistical challenge of integrating him into our team.

As scrum masters, part of our role is to protect developers from undue external pressures and distractions so they can focus on doing the work in the way they think best. But we should not confuse protecting the team with isolating the team, or engaging in workplace protectionism. This can limit how cross-functional our teams are. Of the three pillars of empirical process control that are used in scrum (transparency, inspection, and adaptation), inspection and adaptation require us to objectively evaluate what is best for the team and how to integrate it into the team’s processes, regardless of where those improvements come from. Practicing scrum with that mindset of humility and willingness to accept improvements from sources outside of your immediate team will help your team do better work and make you a more effective servant-leader.