AgileIQ Blog

Product Owner Anti-Patterns, Part 4: Copy the Old One

  

 Email Article  

Tweet  

  

by Monica Yap

In my earlier blog posts in this series, I shared the Absent Product Owner, the Churning Backlog, and the No Single Product Owner anti-patterns. Now I'd like to discuss Copy the Old One.

Anti-Pattern 4: Copy the Old One

This is very common: When the project is to build a new application to replace an old one, the Product Owner does not create stories or prioritize the backlog, since they are “all there in the old application”, therefore we don’t need to start from scratch and should rebuild all the features in the old application. In reality, often the business environment has changed due to changes in the market or work flow improvement, etc., so some of the features in the old application became obsolete, and new requirements have emerged due to the changing environment, so when we rebuild the new system we need to actively trim those obsolete features and add new/change features. Furthermore, if the old application was built in the traditional Waterfall process, there were probably excess features built into the old application due to the “all requirement must specified up front” scenario (see the Standish Group Study below).

When this anti-pattern happens, the team has to “act” as the PO role and learn the old application via code or specification, and many times what they learn is outdated, or the old system didn’t have the correct features according to the documentation. This will causes many frustrations between the PO and team, and trust no longer exists since the team can be perceived as “they didn’t do what they were supposed supposed to do”.

Smells:

• PO asks the team to “just read the old application’s specification or documentation”, “just read the old code”

• PO takes a screen shot of the old application and ask the team to reproduce it

• PO refuses to prioritize or explain the stories

• PO may not know how or why the system behaves as it does

Remedies:

• Help the Product Owner and stakeholders understand:

• The possibility of rebuilding unused features (use industry studies and data like the Standish Group study).

• The old code may be wrong, providing inconsistent or inaccurate behaviors that users haven’t detected, or users just had to “live” with it.

• The old specification may be outdated and not accurate.

• Collect a list of the current user roles and conduct a user story workshop with a representative from each group. Start with the user stories you created in #2, ask them to update them according to their current environment (i.e. market condition, workflow, etc.).

• For each of the features in the old application, use the User Story template (below) to identify the current user role, feature, and value. Note that a user role should not be ‘System’ or ‘other applications’: if you cannot identify the user, then there is a good chance this feature may not been used or the need has changed over time.

• Build up the Product Backlog with the help of the stakeholders to prioritize for the first release.

• There is ROI in multiple releases throughout the project which can mitigate many risks (<fill in for your specific context>), so prioritizing the stories into releases can help gain business value earlier and avoid those risks. Create a high-level roadmap for multiple releases and look for opportunities for early releases -- perhaps a small module can be released and coexist with the current application.

• Identify acceptance criteria for the user stories in the upcoming Sprint, since the team cannot be ‘done’ without properly identifying the story criteria.

Product Owner Anti-Patterns, Part 3: No Single Product Owner

  

 Email Article  

Tweet  

  

by Monica Yap

In my earlier blog posts in this series, I shared with you the Absent Product Owner, and the Churning Backlog pattern. The next anti-pattern I would like to explore is No Single Product Owner.

What does No Single Product Owner mean?

This phenomenon occurs when the business organization does not allow or support single decision-makers as the Product Owner. Sometimes the subject matter experts or stakeholders start acting as product owners. This causes the team to thrash on the different decisions made or directions given by multiple product owners. The team will waste a lot of time and energy to decipher whose decision is correct, and eventually a team member will “act” as the PO and make final decisions, which may or may not align with the product vision, roadmap, or release plan. The person who eventually makes the final decision may incur excess cost to the final product by either specifying excess and/or incorrect functionality. In the worst case, these decisions may cumulatively change the overall product direction.

Common Root Causes:

• The product is too complex or too large for one Product Owner to direct multiple teams and work with multiple product areas.
• The organization believes the Product Owner is merely a part-time role, and multiple people can “fill in” as needed.

Smells:

• During initial release planning, no single person can be identified as PO and determine the release date or scope.
• Conflicting decisions are made by different stakeholders or domain experts.
• Multiple stakeholders or domain experts attend Sprint planning and each one is “in charge” of one or more product areas.
• Team members spend a lot of effort to get final answers from multiple people.
• The project sponsor is a committee and some of the above smells occur.

Remedies:

Try the following for complex and large products:

1. Divide the product into multiple product areas, each with its own backlog and Product Owner. If there is enough work to be done in each area, different product owners can own separate product areas.
2. Have each PO will work with the team(s) on a full-time basis.
3. Propose one person as the chief Product Owner, who in turn owns the overall ROI, and product releases.
4. Create regular Meta Scrum meetings to coordinate between the POs and Chief PO.

Try the following for the PO as a part time role:

1. Measure and summarize the amount of time and rework each team member when there is ubiquitous direction or decisions made by multiple POs. In the case of one team member act as PO proxy, also add in this time spent on preparing the backlog and clarifying questions for a user story.
2. Present this objective data to the senior management and compare the cost effect of having a single PO vs. multiple POs.
3. Propose moving to a single PO to set product direction, supported by the stakeholders/domain experts as his/her product definition team.

If none of the above options is satisfied, raise this as impediment to the organizational level.

Product Owner Anti-Patterns, Part 1: The Absent Product Owner

  

 Email Article  

Tweet  

  

by Monica Yap

After being an observer at the San Jose balancing the budget game event (which was guided by Luke Hohmann of the Innovation Games Company), I realized that most of the software products that are not successful probably have something in common — the enormous gap between the customers and implementation process.

In Scrum, the customers are represented by one single role: Product Owner. An effective product owner can help bring the customers closer to the product through the iterative Scrum process, and can create a natural synergy between the implementation team and the customers. In many half-hearted Scrum implementations, the project teams and end products suffer greatly from an ineffective product owner role, and many of these projects fail. Unfortunately many of these pitfalls are manifested as common hindering and counter-productive practices known as anti-patterns. They are:

• The Absent Product Owner
• Copy The Last One
• The Churning Backlog
• The Waffling Definition of Done
• No Single Product Owner
• Not Enough Stakeholders

I will share these in a series of blog posts, beginning here with The Absent Product Owner.

Anti-Pattern 1: The Absent Product Owner

When the product owner is not available to provide rapid feedback to the agile team, the team does not receive inspection feedback and adapt their work. Nor will the product owner be able to adjust the product design or specification based on the feedback gathered from the actual customer community, as a part of the demonstrated result of each sprint. Instead, the team “self-inspects” and makes decision on their own, falling back to the waterfall process and delivering incorrect features at the end of the project.

Smells

• The product owner communicates the backlog electronically and does not show up to sprint planning or sprint review meetings.
• The team has to maintain the backlog.
• The team has to determine the stories’ acceptance criteria on their own.

Remedies

The only remedy is to work with the product owner and his/her organization to:

• Create a dedicated role and support group for the product owner, so that the product owner is a full-time role on the project; or
• Designate a product owner proxy, which could be one of the team members (although this takes that team member away from implementation). Alternatively, someone outside the team can do a “mind meld” with the product owner and do their best to fill in when the she/he is absent.

If none of these options are satisfied, this impediment should be raised to the higher organizational level for resolution or it should be suggested that the project be aborted.