Monthly Archives: April 2017

There is an “i” in “Agile”

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.

The Danger of a Proxy Product Owner

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.

Problem Proxy Product Owners

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.

What is the danger of having a Proxy Product Owner? The danger of using a proxy is that it often masks organizational problems with the way the role is set up. Many times when I hear “Proxy Product Owner” used, it is used as a euphemism for one of these other types of Product Owner dysfunctions:

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 OwnerThey 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 OwnerThis 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.

Effective Proxy 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 truly have a Scrum Product Owner.

If the term “Proxy Product Owner” is sometimes used when somebody else in the organization has an existing title of Product Manager or Product Owner. When an organization adopting the Scrum framework already has a position description with the title “Product Owner,” role confusion can emerge. 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. In those instances, I prefer the term “Scrum Product Owner” versus “Proxy Product Owner.”

Regardless of the name for the role, make sure that the position is fully capable of fulfilling the responsibilities outlined in the Scrum Guide, allowing that person the best chance of being effective in the role.

What do you think? Please feel free to comment and let me know what your experience has been.