We put a lot of emphasis on being Renaissance workers, able to step comfortably from one job role to the next. But, as Mitch Lacey describes here, not all roles play nicely with each other, and trying to combine them may lead to disaster.
I’ve always prided myself on being versatile. I figure that a modern-day techie is someone who can do a little bit of everything: write code, lead a team, and be able to interact with the customer. So, I’ve always jumped at opportunities that require me to be well rounded—roles that combine management, hands-on tech work, and schmoozing. And, my employers have always loved it because they’ve got one person doing the job of three. Everyone’s happy, right?
Scrum doesn’t work that way. Sure, Scrum asks you to be cross-functional and to learn new skills, but Scrum relies on team members’ functioning solely as team members, ScrumMasters’ working as ScrumMasters, and product owners’ being simply product owners. When someone tries to act as both ScrumMaster and product owner (or ScrumMaster and team member, or even product owner and team member) at the same time, it ends in failure. Trust me. I’ve tried every possible combination—even being all three at once, if you can believe it—and have failed every time. Why? Because these three roles, like the three branches of the US government, are designed to function independently so that each balances and restrains the power of the other two.
Take the combination product owner/ScrumMaster, for example. The product owner exists to drive the team; the ScrumMaster to protect the team. When one person tries to fill both functions, the result is a two-headed dragon doomed to an unpleasant fate: eventually, one head will eat the other. There will come a time when the individual has to choose between satisfying the customer and protecting the team. If the person chooses the team, productivity will never reach optimum levels, the team will steer the product vision, and the customer will lose faith. If the person elects to satisfy the customer, the team will be forced to work at unsustainable levels, quality will suffer, and morale will fall. It’s like a tug-of-war rope or a scale; you need equal weight on each side to keep things in balance.
But, what about the combination team member/ScrumMaster? That seems quite innocuous, right? Although there’s no inherent tug of war between a team member and a ScrumMaster, there is a big difference in focus. The team member needs to work with the other team members to complete the tasks that make up the sprint and deliver working software. The ScrumMaster is expected to ensure that there is nothing in the way of this work and to optimize efficiencies and look for ways to increase performance. The ScrumMaster needs to be able to see the forest through the trees; the team member needs to concentrate on the trees themselves. It’s nearly impossible to do both things well.
A combination product owner/team member is no better. The only upside is that the team will have the product owner in the room most of the time, but that can’t counteract the negative effects. A product owner needs to meet with customers and stakeholders, working to build a product backlog and ensuring that the end product matches the vision. The faster the team goes, the harder it will be for the product owner to keep up. A product owner has to filter too much noise to be able to focus effectively on the work required of a team member. Worse, if Joe the team member can’t get his work done because he’s been too busy with the stakeholders, Joe the product owner can just remove the story from the sprint. Not only will this decrease productivity and sacrifice the vision, it will also degrade the team’s trust in Joe, both as a fellow team member and as a product owner.