Current Episode
Episode 13:
Can our Scrum Master and Product Owner be the same person?
Andrew’s organization is small. Since the company is small, they’ve decided that the Product Owner and Scrum Master need to be the same person. We’ll discuss the possible pitfalls of mixing these two roles and what can be done instead.
Like the podcast? I’d love it if you’d take 60 seconds to rate it in iTunes.
Do you have a question for the show? Submit it at http://GetAgileAnswers.com
Adam: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and agile coach. Each week, I get your questions about Scrum and agility, and I answer them, here on Agile Answers.
Starting a Scrum team can be difficult. You got to figure out who’s going to play what role. And if you weren’t doing it previously, you might be tempted to mix some of the roles. If you haven’t had experience before, it might seem like mixing some of the roles will work out just fine. Well, today’s question comes from Andrew. And Andrew’s team is struggling a bit because their Scrum Master and Product Owner are the same person. Let’s listen to his question and then see if there’s anything we can to do help.
Andrew: Hey, Adam. This is Andrew. Thanks for the podcast. I’m finding it really useful. Here’s my question. My company’s pretty small and we never seem to have quite enough people to do all the work. So we started to do Scrum a little bit ago, and because we don’t have enough people, we decided to make the Scrum Master and the Product Owner the same person. And this seems to be starting a little bit of friction on our team. I’m wondering if that’s the best we can do or if there’s a better way we can organize until we can hire some more people and split up the tasks a little bit better. Thanks a lot for your answer. I look forward to hearing it. Bye.
Adam: Andrew, thanks so much for the question. The situation you’re in is super common. I see it really often in small organizations where they feel like they just don’t have enough people to go around. It’s a really small shop and they figure that mixing those two roles won’t do anything too bad. Or I see it in large organizations who say, “Well, because we’re a large organization, we don’t have any choice but to make the Scrum Master and Product Owner the same person.” I see it in all sorts of situations.
The thing is, it’s not really a great idea. There’s actually a title for someone who is the Scrum Master and Product Owner at the same time. And that title is “God.” The title’s god because if you think about it, the Scrum Master’s job is to protect the team, to coach the team, to be an advocate for the team, to coach them towards sustainable pace and good agile engineering practices. And the Product Owner’s job is to get as much possible ROI out of the team, right? They’re there to get every last cent they can out of the product. They want a good return on investment. And that’s as it should be.
In Scrum, we separated these two roles so that there’s a beautiful tension between the two. Both are advocating for different things, and both equal a fantastic product when done right. But when you try to put both of those roles into the hands of one person, even the most altruistic person in the world can’t possibly succeed.
Now, there’s a lot of things in Scrum where I’ll say, “That’s probably not ideal, but give it a try and check your own empirical data. See how it worked out for your team and for your organization.” This is the one thing, well, one of the things, one of the very few things that I say just don’t try. If you’re not already doing it, don’t go out and do it. And if you are doing it, figure out something else to do instead, because I have never seen a team succeed amazingly well with the Scrum Master and Product Owner being the same person. And I say that after trying it myself.
I took a Certified Scrum Master course and in that course, my instructor told me, “Don’t mix these two roles,” and I went back to the office, spun up a Scrum team, and I tried it as the Scrum Master and Product Owner thinking, “I can wear two hats and I’ll just tell the team when I’m wearing the Product Owner hat and I’ll tell the team when I’m wearing the Scrum Master hat.” And I failed miserably. I failed spectacularly. And I suspect you’re running into a little bit of that with your team. You said that there’s some friction on the team, and I suspect, outside the team as well, because you’ve really been set up to fail.
So I would figure out what to do. I would figure out a way for you not to mix those roles. The easiest way to un-mix those roles or to separate those roles is to have somebody else be the Scrum Master. I think we fall into this trap of thinking, “Hey, the Scrum Master has to be someone of high organizational authority, they need to be an engineering lead or a project manager formerly,” and we also say, “Well, also that person has a ton of product knowledge, so they also have to be the Product Owner.” Well, the Scrum Master doesn’t need any organizational authority. The Scrum Master just needs to know the rules of Scrum, be a good facilitator, be good at helping to remove impediments. By definition, the Scrum Master doesn’t really have any organizational authority other than their own knowledge of Scrum.
So find somebody on your team who’s not currently the Product Owner to be the Scrum Master. It’s fine if they’re also a developer. I think being a Scrum Master is a full time job, but most organizations don’t have budget for that or don’t make budget for that, and so we often see the Scrum Master also doing development work during a sprint, which can lead to some of its own problems, but not the same problems we run into with the Scrum Master and Product Owner being the same person. Those problems are much, much worse. So find somebody on your team who would like to be the Scrum Master or at least like to give it a try.
And if your team is currently feeling some pain from these two roles being mixed, there’ll be some extra energy and maybe excitement about giving this Scrum Master role a try, even if before, they weren’t super excited to be the Scrum Master. Maybe before, your organization asked who would like to be the Scrum Master and the only one who volunteered was the person who also volunteered to be the Product Owner. Well, just don’t do it.
Separate those roles. Have them be separate, and you will see that your team does much, much better, I suspect, because really, currently, they’re on a fool’s errand doing both of those things at once. Not to mention that the Product Owner job is a full time job. It is a full time job and if that person is also supposed to remove impediments for your team, good luck.
On a Scrum team that’s set up correctly, would I expect that from time to time a Product Owner would remove an impediment? Yes, that’d be fantastic. But that’s not their full time job. Their full time job is to get the product backlog in good shape for the team to execute upon. And if they don’t spend a bunch of time getting the product backlog ready for future sprints, talking to stakeholders, talking to customers, getting feedback, etc., their team isn’t going to have the stuff they need to be successful. Their product isn’t going to have the stuff it needs to be successful. And it’s just another way that mixing those two roles will help you.
So Andrew, I guess the bad news is you hit on one of the only things that I’d veto. I would say just don’t ever do that. The good news is it’s not that hard to fix. Your organization just needs someone else to be the Scrum Master or someone else to be the Product Owner. And while that might seem impossible at first, maybe for political reasons, maybe because your organization is small, maybe because you don’t have an experienced Scrum Master other than the person that’s also the Product Owner, it’s not that hard to fix. You just need somebody who is willing to give being a Scrum Master a try. And since you already are seeing friction on your team, you have some good data to point to in your organization that shows, “This isn’t working so well. Let’s try something else.” Empirical process control is fantastic like that.
Thanks so much for submitting the question, and I hope my answer was helpful. If someone else out there has a question they’d like featured on the show, then can go to GetAgileAnswers.com, that’s GetAgileAnswers.com. Right there on the home page, there is a little widget where you can record a question to have it answered, perhaps, on a future show. If your question gets answered on a show, like Andrew’s did, you’ll get a pack of my Agile Antipattern Cards. In fact, Andrew, a deck’s on its way to you as we speak. If you’d like to submit your question anonymously or you just don’t feel like speaking into the microphone to record it, you can also drop me an email. There’s a link there on the page where you can submit your question by email.
Until next time, stay agile. Never change.
Past Episodes
Episode 24:
What should we do instead of painful “Annual Planning”?
Episode 23:
Agile Virtual Summit Preview: Lyssa Adkins
Episode 22:
How do we make sure we have cross-functional teams and why does it matter?
Episode 21:
What agile practices can you recommend to our game development studio?
Episode 20:
How do we remove silos when doing government contract work using Scrum?
Episode 19:
How should we form new Scrum teams?
Episode 18:
How can we have good retrospectives (about our Scrum Master)?
Episode 17:
When’s the podcast coming back?
Episode 16:
How do we self-organize if our boss is on our team?
Episode 15:
How do we deal with constant interruptions to our Sprint?
Episode 14:
Can a User Story be too long? Ours seem insane!
Episode 12:
What 1 simple thing can I do to improve my coaching & scrum mastering?
Episode 11:
How do I get hired as a ScrumMaster if I’ve never been one before?
Episode 10:
Our team wants to be more agile. What agile process is best?
Episode 9:
How do we improve our giant, multi-team Sprint Review session (or Sprint Reviews in general)?
Episode 8:
What are some creative & effective ways to make Retrospectives more engaging?
Episode 7:
Will this hurt my Daily Scrum? And how do we deal with “non-dev” work?
Episode 6:
How do I escaped the dreaded ‘Scrummerfall’ trap?
Episode 5:
How do you help PMs and Managers not fall back into their waterfall ways?
Episode 4:
Our teams keep changing. How do I set guidelines that keep teams together?
Episode 3:
How do you make sure your team has time to make the improvements they identify in their Retros?
Episode 2:
When should the business stakeholders get help from the dev team to get items ready for work?
Episode 1:
How do I energize a demotivated Scrum team?
Mic Check! 1…2…3…