[Product Owner – Dev. Team] Ladder of Empowerment

“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” – The Scrum Guide.

When the whole  Scrum Team is self-organizing (in addition to the Dev. Team being self-organizing in executing the Sprint Backlog), understanding the context of Product Owner – Development Team relationship is important (and this is probably one reason why various scaling frameworks have conflicting take on the role of a Product Owner). I call this model the “[Product Owner – Dev. Team] – Ladder of Empowerment”.  This model assumes that we do not have a “dysfunctional” Product Owner

1. Directing – Dev Team members are seen as order takers and they do what they are told to do. Dev Team tend not to be informed of the business/ marketplace, and the context of the problem/solution. Clarification of PBIs is usually be in written format to ensure “correctness” The real PO (decision maker, but may not be called PO) usually uses a dummy PO (who might be labeled as “Product Owner”, but is not the decision maker) to engage with the Dev. Team. Dev. Team’s communication is usually restricted only to the real PO and/or the dummy PO. The real PO does discovery, and the dummy PO may usually write, clarify and refine PBIs for the Dev. Team. There may be lot of finger pointing and blame.
   • Level of Trust and Engagement – Non-participation by Dev. Team
2. Decoration – Product Owner engages Dev. Team in extensive, but superficial, non-value add activities. PO creates an illusion of participation (e.g. seeking feedback) but does not care about the information provided. Ideas and problems brought up by the Dev. Team are trivialized. The purpose of this type of engagement is primarily focused on making the Dev. Team feel engaged rather than using the engagement to influence decisions and outcomes, with a view to changing the Dev. Team’s perspective while minimizing their actual ability to create change. PO owns discovering, clarifying, refining, and writing PBIs. The “real” PO may also use a dummy PO to delegate work and for indirection of feedback. Clarification with others other than real/dummy PO is explicitly forbidden
   • Level of Trust and Engagement – Non-participation by Dev. Team
3.  Informing – Dev. Team knows how they can participate, but emphasis is placed on one way flow of information from PO to Dev. Team with no channel provided for feedback and no power to share useful information that Dev. Team may have. Information is provided to Dev. Team at a late stage ensuring that they have little opportunity to contribute or influence to the product and Product Backlog. PO does product discovery, refinement, and writing PBIs. All clarification needed by the Dev. Team is done by the PO and clarification with others is implicitly forbidden.
   • Level of Trust and Engagement – Non-participation by Dev. Team
4. Consultation –  Not all information will be shared with the Dev. Team and Dev. Team only have partial context of the business problem. Dev. Team’s input is sought by Product Owner (e.g. technical feasibility, design, etc.). Product Owner unilaterally make decision using/not using the information based on other criteria (market conditions, stakeholder satisfaction, regulations, etc.) PO does product discovery, clarification, refinement, and writing PBIs. Dev Team may clarify PBIs with others when doing development. There are no dummy POs and the real PO engages in discussions with Dev. Team
   • Level of Trust and Engagement – Token participation by Dev. Team. PO holds the ultimate decisional authority
5. Placation – Dev Team will have some degree of influence in the direction of the Product and the Product Backlog. Some dissent opinion will be included in decision making, primarily to give a feeling of inclusion and participation. It might also include opinion of hand-picked representatives or agreeable “voices”. PO does discovery, initial clarification, refinement and writing PBIs. Dev Team may further clarify PBIs with others when doing development.
   • Level of Trust and Engagement – Token participation by Dev. Team. PO holds the ultimate decisional authority
6. Partnership – High transparency between PO and Dev. Team. All information available to everyone. PO considers the Dev. Team as equal partners and they collaborate to makes final product and Product Backlog decisions based on desirability, viability and feasibility. PO provides the context of the customer/market problems (PO is the teacher of Product, customers, market and educates the Dev. Team). Dev. Team strives to understand customer problems and provides technical solutions. There is no unilateral decision making by the PO. PO usually does discovery, and empowers the Dev. Team to do refinement, clarification, and writing PBIs. PO is accountable for the final product and product backlog, the accountability and success attributed to collaboration with the Dev Team
   • Level of Trust and Engagement – Engaged Dev. Team.
7. Delegate Responsibilities – PO teaches, and coaches the Dev. Team to discover customer problems (and the actual discovery is done by the Dev. Team, not the PO), but is ultimately accountable for the success of the Product. Dev Team is engaged with stakeholders, users, buyers, and customers in discovering customer problems, crafting customer solutions, clarifying, refining, and writing PBIs. PO focus more on educating the Dev. Team to make right product decisions. Dev Team uses the PO as a sounding board (a coach or a mentor) to make right Product Decisions. The Dev.Team understand that they are also responsible for the success of the product in the market place and uses PO as the lead decision maker
   • Level of Trust and Engagement – High Trust and engagement. Many responsibilities delegated to Dev. Team.
8. Empowered Dev. Team –   All of (7) + Dev. Team understands the context of the product, the customer problems, market conditions, regulations, and takes ownership of many tactical aspects of product development from discovery to delivery freeing up the Product Owner to focus more on strategic priorities. Dev. Team can make right product decisions (and the PO trusts those decisions) and defend the decision to the PO. Dev Team can even challenge PO decisions based on market data/customer insights (but the PO will remain the lead decision maker, and the Dev. Team will always respect PO’s final decision). PO is ultimately accountable for the success of the Product, success attributed to PO empowering the Dev. Team and Dev. Team making right product decisions
   • Level of Trust and Engagement – Very High Trust and very high engagement

What are your thoughts? What aspects of these have you seen in your experience?