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.