To place this article in its proper context, let's define what a product owner is. In other words, what is his or her role in Scrum, and what type of attitude makes a good product owner?
I could write a full post to discuss this, but I don't need to reinvent the wheel. So I'm going to quote the description of a product owner from the Scrum Guide
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item's priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner's decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn't allowed to act on what anyone else says.
With the definition now out of the way, I'm directing your attention to the subject of my article: why Agile is the Twilight Zone for some product owners and stakeholders.
First, some product owners and stakeholders don't really understand Agile. They don't understand the benefit of leaving the old Waterfall model and transitioning to Agile. I can understand that leaving the old model means leaving exhaustive planning and documentation, milestones, control, and micromanaging behind. It's human nature, so it's always trying to pull us back. This means that we need to drive the effort to overcome this old way of thinking.
It's really difficult to understand why, instead of delivering full functionality after one or two years, we should deliver small packages of software (MVP) to be able to validate and get feedback.
I think that this lack of planning and existing transparency is the cause for some teams always crossing over into the Twilight Zone.
Let's imagine a world where:
- You have self-organized teams, and you don't need to assign any task or tell them what and how they should do their work inside the sprint. It's better at the end of each sprint when you have a working package that you can test, validate, and provide feedback on.
- During the grooming, you can count on the support of your team (yes, a product owner is part of the team) to help you analyze any dependencies and provide technical feedback to help achieve a product with high quality and performance.
- You don't have impossible milestones dates because everyone is working toward the MVP.
- You can keep the feature quality high but, if needed, you can reduce the scope. Depending on the importance of the delivery business value, you can update the delivery date.
- Constant communication, transparency, and collaboration are principles that are rigorously upheld.
- You can build ideas that can be measured to determine whether they were a success. By being able to measure the success rate of an idea, you can continue to improve in every iteration instead of wasting a lot of effort on the wrong ideas or tasks.
Well, this can be a real Twilight Zone for many people!
In my opinion, this way is too difficult for them to undergo a 100 percent transition to Agile. Worse, this can create anti-patterns of adoption that will cause Agile to fail.
Below are some of the anti-patterns of Agile adoption that I've identified during the course of my career:
- More than one product owner exists for the same team. This automatically creates "noise" for the team because it doesn't have a clear business priority.
- The product owner micromanages, sometimes acting as line manager. This is an issue for any self-organized team. It breaks the team symbiosis and creates interference for the team and their daily work during the sprint.
- The team has changed the objective of the daily stand-up to a daily status report. This goes against the real reason for the daily stand-up, which is from the team to the team.
- Big work items are impossible to break into smaller work items. Team members are so stressed by trying to have everything ready (full product or feature) that they forget that big work items can contain hidden complexity, causing blockers and carry-overs. The inability to break the big items is also a demotivating factor to the team.
- There is no sprint objective. Sometimes the absence of an objective is meant to camouflage the lack of business value prioritization.
- The backlog is neither well defined nor transparent. This is also to camouflage the lack of business value prioritization.
- The product owner lacks the power to make decisions, which leads to a proxy product owner. A delay in clarifying doubts is due to a lack of backlog prioritization.
- The product owner uses high-level estimation provided by the team to agree with the stakeholder on the delivery date. This way leads to milestones written in stone.
- The product owner is too busy for the team. Should a product owner always be busy and without time for the team?
- The team asks to decrease quality to meet a fixed date agreed with the stakeholder.
How should we address all these anti-patterns? We can always blame the product owner, but we need to act as a team. This means that we need to work together and collaborate with them all the time, as a Scrum team.
When I encounter any of these anti-patterns, I do the following:
- Talk with the team to understand the stage they're in. What is their concern? Why are they so reluctant to change?
- Train them so that they can have a full understanding of Agile and its benefits.
- Changing their mind-set is not like turning on a switch, so I spend most of the time talking with them, coaching them, and supporting them.
- To fully understand what the team needs and act as a proper team member, I make sure that the product owner is full-time, committed, and colocated with the team.
I do this with the hope that one day they have a full understanding and accept the change as their own.