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…)

Ill-defined Roles Block The Elevator!

As I considered the intricacies and difficulties of the Product Owner role, I was concerned that my perceptions might not be as inclusive as possible. In order to expand my understanding of the role and to test my experiences, I asked over fifty product owners why they thought the role was hard.  The majority responded and I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are:

  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 product owner role is difficult, and perhaps consistently more difficult than any other role in software delivery.  Part of the difficulty is a reflection of information asymmetries, other difficulties arise because of how we use words or who is assigned to be product owners.  The next two of most common reasons the product owner 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…)

Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

The idea of a Scrum of Scrums (SoS) is fairly simple. A bunch of people get together on periodic basis to coordinate the work their team is doing with other teams. The SoS helps everyone involved work together in order to deliver the maximum value. The SoS typically use the daily stand-up or scrum as a model. The simplicity of the logistics of the SoS and the overall utility often leads to tinkering with the format to address other organizational needs. Four very typical additions include: (more…)

How can this team really work together?

How can this team really work together?

I recently got a question from a long-time reader and listener.  I have removed the name to ensure confidentiality.

Context:

  • The person who asked the question is an experienced Agile leader.
  • The team is not all technically-equal full-stack developers, some developers work on UI stories and others work on backend stories.
  • The team has 8-10 people.

The Problem:

  • During story grooming/sizing, the entire team does not participate equally to offer up their points. UI developers participate on UI stories and are reluctant to chime in on backend work, and vice-versa.

The Question:

  • Scrum seeks to involve the entire team.  How can I get everyone involved (or should I)? 

(more…)

XP Explained

This week we begin getting into the proverbial weeds of Extreme Programming by tackling chapters six and seven in Kent Beck’s Extreme Programing Explained, Second Edition (2005). Chapters six and seven explore the practices that operationalize the values and practices we have explored in previous installments. (more…)