There’s a popular phrase that states “there is no ‘I’ in ‘team.'” This slogan appears on shirts. It appears on posters. It is popular enough that the phrase has been “hacked” and now there is a funny graphic that says “There is an ‘i’ in Team. It’s in the a-hole.”
There is an “i” in “TEAM.” Hidden in the A-Hole. (Copyright belongs to the image’s creator)
What might that phrase mean to an agile team? There is a SolutionIQ article that states “There is no I in Agile” and discusses how teamwork can make or break an agile team. I agree that teamwork is important. But, contrary to the SolutionsIQ heading, there is an “i” in “agile.” And it is important that we remember that the agile team is made up of a whole bunch of “i’s.” Here are some of the ways to make the “i” in “agile” effective. Work to help each “i”:
- i realize that i cannot be successful if the team fails
- i look for ways to help teammates
- i bring new ideas into the team
- i am willing to take risks
- i admit when i need help
- i admit when i am wrong
- i grow my skills over time
- i build upon other people’s ideas with my own
- i bring my whole self to the team
- i try to not be defensive
- i realize others bring their whole self as well
- i realize that the world outside work impacts people at work
- i take small risks and learn from the outcome
- i respect my teammates
- i foster collaboration across the team
- i use my eyes to observe what is happening on the team
- i am a “little i,” not demanding the attention of a big “I”
Remember that your team is composed of many individuals, each with their own background, values, and perspectives. Work to be inclusive of those differences as you work toward a common goal.
Imagine that you’ve read the Scrum Guide’s description of Product Owner role. You see that in order to be effective, a Scrum Product Owner needs to
- Keep the Product Backlog groomed
- Ensure understanding amongst the Scrum Team, and
- Negotiate with the Development Team
That takes a lot of time and energy. You realize that the role is so involved that you can’t possibly have your current “product owner” fulfill the Scrum duties as well. You are contemplating using a “Proxy” product owner to fulfill the Scrum Product Owner’s duties. The Proxy Product Owner will not be the real product owner, but they represent the product owner and have the responsibility for communicating the product owner’s perspective with the team.
To fulfill these responsibilities, of a Product Owner, the individual in the role must have the
- time to do the work completely
- knowledge of the product and customers’ needs
- authority to make decisions
Can a Proxy Product Owner be effective? Is it a good idea? Will that work? Let’s explore it a little bit.
Proxy Product Owner
The term “Proxy Product Owner” is sometimes used when somebody in the organization has an existing title of Product Manager or Product Owner. There may already be a position description that corresponds to a title of “Product Owner.” In those cases, it can be valuable to differentiate the Scrum Product Owner from the other duties that are wrapped into the existing title of Product Owner.
A “proxy” is someone who can make decisions on behalf of another. If the person filling the Scrum Product Owner role can completely and truly fill all the responsibilities outlined in the Scrum Guide, then you have a Scrum Product Owner. And, if calling them a “Proxy” Product Owner is synonymous with Scrum Product Owner, and helps differentiate the Scrum activities from the other organizational activities that are across the two Product Owner titles, then it can work well.
What is the danger of having a Proxy Product Owner? Many times when I hear “Proxy Product Owner” used, it is used as a euphemism for one of these other types of Product Owner:
Dysfunctional Product Owner Models
|The Ignorant Product Owner ||They lack the knowledge necessary to fulfill the role. They are constantly having to go out and gather understanding from someone else who truly has it. Or, worse, they guess at the answer and inject wastefull activity into the team.
|The Impotent Product Owner || They have no power to make decisions. They have to go play "mother may i...." with people who really make decisions. This delay negatively impacts the team.
|The Indecisive Product Owner||They have all the information and authority to make decisions, but they're still incapable of deciding. The causes of indecisiveness vary, from fear of punishment for wrong decisions to over-analysis.
|The Overworked Product Owner||This person simply has too much work for one human to do. It is impossible for them to keep the team supplied with a properly groomed backlog, leading to frustrating and ineffective Sprint Planning and delivery.
Overworked Product Owners can neither keep the backlog groomed nor be available to the team.
An Indecisive Product Owner can kill the team’s momentum.