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”.
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
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.
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.
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.
- 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.
Try the following for complex and large products:
- 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.
- Have each PO will work with the team(s) on a full-time basis.
- Propose one person as the chief Product Owner, who in turn owns the overall ROI, and product releases.
- Create regular Meta Scrum meetings to coordinate between the POs and Chief PO.
Try the following for the PO as a part time role:
- 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.
- Present this objective data to the senior management and compare the cost effect of having a single PO vs. multiple POs.
- 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.
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.
- 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.
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.