Scrum often makes reference to a classic joke regarding a pig and a chicken. The chicken wants to partner with the pig to start a restaurant. The pig says, “No thanks” to the chicken because the pig would be committed while the chicken would only be involved. The Scrum world typically defines a Scrum team as a team of pigs. The chickens are all the other “stakeholders” that don’t have their own skin in the game, and are not members of the Scrum team.
I recently participated in an ongoing debate by several members of the Scrum Practitioners group on whether the Scrum Product Owner should be an active member of the team. For those of you that are not as familiar with the title, the Product Owner is usually one person who is accountable for the product. This role usually is, but not limited to, a product director, product manager, or business development resource. Where does your Product Owner fit? Are they a chicken or pig?
A Team of Pigs
Scrum typically defines the product team as:
ScrumMaster – This person facilitates the objectives of the team and remove obstacles.
“Product Development” Team – The software developers, designers, testers, etc. who build the product
Product Owner – The person who define user stories, set priorities for the team, and clarifies questions from the rest of the team.
The UI/UX designers and technical architects are sometimes included and sometimes not (a topic for another day).
The Scrum Product Owner is the dirtiest of the pigs.
The Product Owner is the single “wring-able neck” for the product. They typically are responsible for the return on investment (ROI) and will be answering to the executives and business partners if something goes wrong. So it benefits everyone to have an active product owner in the process. I would recommend that your Product Owner attend the daily stand-ups. He or she should keep quiet unless someone has a question or someone is not following the plan (even then, bring it up with the ScrumMaster). The P.O.’s goal at that daily stand-up should be to find out when/if something is off target as soon as it happens and to answer any scope questions that come up from the team.
Other than that, I would imagine most Product Owners will be too busy to engage in other activites during a sprint. They should be too busy with their other responsibilities. The Product Owner most likely will be busy coordinating with the chickens, preparing the next sprint, helping define test cases, and ideally working with the business to get feedback from the product user base/market.
Shouldn’t the ScrumMaster protect the team from the “business?”
Some of the issues raised during the debate centered around the notion that the team should be left alone to work. Disruptions and unnecessary change are things to be avoided, the argument goes. Questions arise like:
- Why should the Product Owner have any involvement with the team?
- Shouldn’t the P.O. just write the user stories and go back to their “business work?”
- Isn’t the point of Scrum to isolate the team and “put them in a bubble?
The goals are admirable, but I caution against those attempting to place their development team in a protective bubble. I counter those questions by asking:
- Why are you doing Scrum instead of Waterfall?
- How can you be agile and adapt if a core member of the team disengages?
You need to be able to adapt to change. You need to know when you are off course. You should want to have a development team that understands what they are building and why they are building it. The goal of Scrum is to achieve business value by repeatedly inspecting and adapting as you learn. You should isolate the team from changing requirements and interruptions, but not from outbound requests for clarity.
In an ideal world, user stories would be written perfectly, sprint planning meetings would deliver a nirvana of understanding, and there would be no need for questions or change. But that premise of “perfect enlightenment” is the same weakness of the Waterfall model. Learning happens after sprints and releases, but it certainly happens during the sprint. If you want to maximize the team’s potential, you need to course correct at the first sign of trouble (This is more a Lean principle than a Scrum one).
There’s a class for Product Owners??
Most people that are familiar with Scrum know about the ScrumMaster role. The Scrum Alliance does have a Certified Scrum Product Owner (CSPO) class) as well. Some organizations, out of necessity or ignorance, will combine the two roles. I have seen it done, I have done it, and while it can work, it’s not ideal. The ScrumMaster is there to protect the team. The Product Owner is there to protect the product. When the two come into conflict, will one person be able to balance both of those responsibilities?
If your organization is implementing Scrum, I highly recommend that your product owner be CSPO trained. Your product owner is accountable to your development team, and vice-versa. It is essential to have a Product Owner that understands their responsibilities in building software.