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?

Not always.

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.

Combining all three roles—a situation I affectionately refer to as the “trifecta of death”— is an exceedingly bad idea. Here’s what usually happens: One valiant soul agrees, for the good of the team, to be both product owner and ScrumMaster. And, since neither of those roles is too taxing (oh my!), she agrees to take on a few stories in her spare time. Pretty soon, she’s doing all three roles pretty badly as she struggles to juggle the competing work. Plus, she’s making compromises that degrade trust with her team and with her stakeholders. By trying to do it all, she’s doing nothing well and is actually harming her team and the end product.

Now, I will grant you that there are some instances in which wearing multiple hats can work and makes sense. In small shops, where you only have one team and that team only has three people, you’re probably going to have a combination ScrumMaster/team member and maybe a combination product owner/team member. My advice to you in these situations is to be clear when communicating with your fellow team members which hat they are wearing at the time. Are they talking to their fellow teammate or their product owner? Try to dedicate a certain number of hours to each role so that you spend a dedicated portion of each day or week focused at the right level.

In larger shops with multiple teams, when time or personnel constraints dictate that certain people wear multiple hats, I recommend having one ScrumMaster or one product owner work with multiple teams rather than splitting time between roles. Or, work as a ScrumMaster for one team and a team member for another. It’s not ideal, but it’s better than working in both roles on the same team.

It’s good to be able to wear multiple hats, and it’s important to look for ways to expand your skills. But, it’s imperative to keep the three Scrum roles distinct and independent. It’s as essential to a healthy project as working in sprints and doing daily standups. Is it possible to have a stool with two legs, a balance with no counterweight, or a Scrum team with combined roles? Yes. Will they be high-functioning? Never.

This article is an excerpt from Mitch Lacey’s forthcoming book on surviving your first year with Scrum.