One of the trickiest problems that Scrum teams face is whether to allow a Product Owner to serve as a team member. Most Certified Scrum Trainers I’ve heard discuss the topic recommend that Product Owners not be a part of the team. The problem is that when a Product Owner participates in the team’s day-to-day activities, he or she undermines the team’s ability to self-organize. That’s not to say that Product Owners willfully sabotage a team’s chance at success. On the contrary, the sheer difference of the Product Owner’s “status” exerts its influence on the team’s perceived sense of autonomy to choose its course of action. For instance, Scrum asks that when a team estimates the level of effort it will require to complete a given story, the Product Owner not attend so that all team members feel at ease to honestly evaluate the story’s level of difficulty.
This problem gets even trickier if your Product Owner is also your Boss with a capital B. For smaller organizations, it’s not uncommon that the president or CEO would also act as a Product Owner. When that happens, it might be even harder to ask that he or she limit her involvement in the Scrum team. But the same rules apply. For Scrum to truly facilitate hyper-performing teams, those teams must be empowered to decide how they pursue their work. After all, that responsibility is accompanied by a sense of ownership over its success and a commitment to realize that success that is shared with the rest of the team. Besides, when a team is experienced at making tough decisions to get results, that frees up the Product Owner—and, in this scenario, president or CEO—to think about big-picture strategy. In that sense, Scrum is a sensible framework because it acknowledges that the Product Owner can’t—and shouldn’t—have his finger in every aspect of the business. Instead, Scrum recognizes the necessity of distributing both responsibility and authority.