Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

This week’s Software Process and Measurement Cast features our essay revisiting the product owner role. The product owner role is hard, often messed up and a great opportunity for improvement.

The second column features the return of Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 17 which is titled Challenges of Work-State Work in Process Limits. WIP limits have their plusses and minuses when discussing hyper-productivity.  

Our third column this week is from Jeremy Berriault. Jeremy discusses how to show the value of QA and why knowing and showing value is important!   Jeremy  blogs at https://jberria.wordpress.com/  

 

Re-Read Saturday News

This week we tackle Chapter 6 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.   Chapter 6, Facilitating Governance, puts the ideas and processes defined in governance to work. (more…)

Control!

The product owner (PO) role is incredibly important in any Agile effort. The product owner leads, manages and prioritizes the backlog and networks with stakeholders, customers, and developers of all stripes.  All sorts of problems can beset the role. However, most of those problems are either self-inflicted or a result of poor organizational design.  A laundry list of problems based on observation and responses from other product owners include:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The next set of difficulties are: (more…)

Accept no substitute.

The product owner (PO) role even when performed as described straight out of the book is difficult.  The role is often even more difficult than it needs to be, with information asymmetries between the PO, the team and stakeholders ranging to ill-defined roles. I asked over fifty product owners about why they thought the role was hard to augment my perception. I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are: (more…)

Doing the Product Owner Role Poorly is Like Drowning!

The product owner role is evolving in most organizations. The role has its roots in the roles of product managers, project managers, business subject matter experts (SME) and project sponsors from other methods.  The roles and the responsibilities of the role are critical in any Agile approach to delivering value. The product owner role is difficult, and perhaps consistently more difficult than any other role in software delivery.  The reasons the role is difficult can be traced to several solvable scenarios. The most common reasons are: (more…)

Super Sponsor

Super Sponsor

The product owner is the voice of the customer and performs a significant of a number of activities, including acting as a conduit/facilitator for communication between the team and the outside world.  Other activities include: defining and elaborating stories, prioritizing the backlog and accepting work when the team completes a story.  The product owner’s role is related or influenced by the sponsor’s roles (sometimes known as executive or project sponsor).  The sponsor is the person that has overall responsibility and accountability for a piece of work.  The sponsor champions the project based on whether the work fits the business’s needs and overall strategy, finds and secures the budget and has the overall responsibility for the work to deliver the promised value. This is true even though he or she will probably never write a line of code or test.  Sponsors empower the product owner to act for them on a more tactical basis.  A comparison of how the sponsor’s typical roles translate to the product owner is shown below: (more…)

264237296_864c89a913_z

As we have seen, product owners act as a conduit between the business and/or customers and the team. The product owner’s role encompasses not only the definition of what gets done and when, but also the level of quality of what gets delivered.  One of the facets of the role affecting quality comes when the product owner participates in writing the acceptance criteria for user stories.  Acceptance criteria are part of well-formed user stories and are crafted early in the life cycle when stories are generated and refined as they are groomed.  The product owner role provides another check on quality and occurs when the product owner uses his or her authority to accept completed stories.  I don’t want to suggest that the product owner is only active at the start and end of a sprint or iteration. The product owner interacts with the team on a continuous basis in order to guide the work and the culture. Adoption of acceptance test-driven development (ATDD) is an excellent method of instantiating the product owner’s role in both shaping the vision for the team and influencing the quality of the work a team delivers. (more…)

img_2572

Product owners play a pivotal role in all Agile projects. This is true whether a product owner exists or not. Since the role is so critical it should be easy to define the role of product owner. However, most definitions tend to quickly devolve into a list of responsibilities that depend on implementation and scale.  One of the most critical and often most variable roles of the product owner is that of the interface between the team and the outside world.  The outside world includes users, customers, stakeholders, sponsors, and sometimes other product owners and teams. We can visualize the interface role on a continuum that on one end includes the product owner acting as a highly structured conduit for information from outside the team to a facilitator of conversations on the other end of the continuum.   (more…)