Project Managing PO and Other PO Anti-Patterns - Part 2
A continuation of project managing and other product owner anti-patterns and what can be done to address those anti-patterns.
Join the DZone community and get the full member experience.Join For Free
In Part-1 of this article, we saw how some POs manage the team, interfering in their internal tasks, and questioning them on the need for DevOps activities and other tech debt tasks.
In Part-2, here are more anti-patterns and some suggested remedies.
6. If This Story Is 5 Points, Why Is the Other 8?
This shows the POs lack of understanding of relative size estimation using. The relative estimates are based on many conditions such as complexity. Uncertainty and volume and are best determined by the team. A 5-point story cannot be strictly extrapolated to arrive at an 8-point story though the 5-pointer could be used as a rough guideline. And the PO is not the person to do that because the PO would not have the insight into the technical complexity or implementation challenges of a given story. The PO should just leave it to the team to arrive at the story points of the stories.
The ‘estimating’ PO curtails the freedom of the team to arrive at the right size of the stories. This anti-pattern, if persists for a long time, would limit the creativity of the team to think aloud on implementation strategies exploiting the available tools and technology.
7. Why Should You Spend Time Coordinating For Dev and QA Environment Configuration?
If not the team who else should get the environment set up for development and QA? The PO should realize that the team needs the appropriate environment for development. QA and UAT. Though with DevOps practices such as Infrastructure as Code could help here, until they reach a mature state of automation and self-service the team has to coordinate with the infra team to get their environment set up.
I have seen teams where their application worked perfectly on a box and crashed on the other one with ‘identical’ (according to them) configuration. The team needs to work with others to investigate such issues and make sure the configuration across different hardware is consistent. Without adequate time for infrastructure setup and testing, the team would potentially end up with insufficient testing and runtime issues related to misconfiguration. This will not only lead to team frustration but also result in end-user dissatisfaction at the time of UAT.
8. Sprint Goal Is Same As the Product Vision and Will Not Change From Sprint to Sprint
Here the PO insists that the product vision is the driving force and a Sprint simply picks up some part of the vision. So essentially the Sprint goal is a diluted version of the vision and will remain the same for all the Sprints. This clearly shows that the PO is unable to visualize how the solution could be delivered in smaller increments, steadily adding valuable functionality. Because of this, the PO is not able to define the goal that a given Sprint is expected to achieve.
Without a clear goal in the context of the given Sprint, the team is not focused and the team will not appreciate how the Sprint’s deliverables fit into the broader picture of the product. I have seen team members mechanically coding to meet a story’s intent and when asked about what value the Sprint was expected to add to the business or how their work would contribute to the business objectives they just go clueless. This trend does not motivate the team to do their best in realizing the business vision. Frequently even the PO fails to logically put together the output of the Sprints to articulate the business value delivered by the team.
9. Acceptance Criteria Will Be ‘Story Is Signed Off By the End-Users’!
Isn’t the story sign-off based on acceptance criteria? And wouldn’t the acceptance criteria include the story’s specific scenarios to be addressed? The PO and the business stakeholders do not understand the significance of the acceptance criteria. They think it is an overhead for them to write the acceptance criteria. I have even seen POs asking the teams to write the acceptance criteria. How would this be fair? The development team would write the acceptance criteria based on their interpretation of the story and their technical approach to implement it. And often this will be complete and miss out on key business scenarios. The POs cannot shy away from writing the acceptance criteria.
Lack of acceptance criteria has many implications. Without accurate and complete acceptance criteria the team will not be able to fully test their technical implementation of the story. For example, the testers will not have all the necessary test scenarios to test the stories. In the Sprint Demo, the PO and the business stakeholders will not be able to validate the implementation of the story. Acceptance criteria render Behavior Driven Development (BDD) much easier for the team. Without acceptance criteria, test automation will be harder.
10. Give Me the Breakup of Time Spent On Each ‘Stage’ Story, Starting With Definition and Analysis Through Dev, QA, Integration, and UAT.
This is perhaps the best example of a project managing PO! One of the Agile principles states that working software is the only measure of progress. But some POs ask for the status of each story as it moves through the Sprint. They assume waterfall stage gates within the Sprint and want to know the time taken by a story at each of these stages. Sometimes they even go to deeper details and ask questions such as ‘How much time will you need to write test cases? Give me some examples of the unit test cases and justify the time needed to create those..’!
This approach is detrimental to the team’s adoption of Agile principles. The team would just end up using Agile terminology and continue to use the waterfall approach to meet the PO’s expectations. They are forced to keep track of the stages and time spent on each. Will they work to produce working software or track the time and effort? This monitoring approach employed by the PO puts additional pressure on the Scrum Master to monitor the team’s effort and report the stagewise effort. Should the Scrum Master focus on removing blockers for the team or monitor their effort?
What Can Be Done To Address These Anti-Patterns?
These anti-patterns could manifest in different ways in different organizations. Therefore the remedial measures are in fact specific to a given context – as Disciplined Agile says ‘Context Counts’. One will have to take into consideration factors such as the organization culture, their transformation vision and timeline, the business readiness for transformation, the leadership willingness to drive the right behavior across the enterprise, and so on. Here are a few general suggestions that could be considered.
1. Prepare the Business for Agile Ways of Working
This is perhaps the first step in an Agile transformation. Get the buy-in from the Business leaders to embrace an Agile culture. The leaders have to realize the benefits of Agile ways of working and only then they will be able to influence their next levels such as the Product Owner to adapt to the Agile ways of working.
2. Keep the Communication On
While at the start of the Agile transformation and throughout the journey keep reinforcing the Agile values and Principles. Include webinars, expert talks, success stories, etc. in these communications as appropriate.
3. Establish a Team Working Agreement
Called by different names such as Team Norms or Team Agreement, this is a set of practices based on Agile principles that the team agrees to follow. This agreement covers practices across different roles and ceremonies at a level of abstraction determined by the team. In the early stages of Agile maturity use this agreement to show not to use the command and control approach to monitor the team – highlighting what the PO should and should not do.
4. Consider Coaching
Often with the monitoring approach of the PO, the Agile teams tend to move away from the accepted Agile practices and resort to ad hoc methods. An Agile coach could help the team in reinstating the Agile values and principles and keeping the team on track with those principles. Depending on the experience and the bandwidth the Scrum Master could also be the Agile coach
5. Educate the PO
This is the top mitigation strategy item to address the PO anti-patterns. Include the PO in all the key Agile training programs – starting from the initial orientation through the role-based deep-dive sessions. Where found necessary get the Agile coach and the Business leadership to conduct one-to-one sessions with the PO to emphasize the need for team empowerment, trust, and transparency. Highlight the negative impact of project managing and monitoring the team Make sure that the PO attends all the sessions of the PO Community of Practice or ‘guild’. Where feasible get other Pro-Agile POs to share their practices and success stories
Opinions expressed by DZone contributors are their own.