Which is more important to first get right: Effectiveness or efficiency? Intuitively many choose first to be effective: Just get it done, worry about doing it properly later. This approach may produce short term gain but it is disastrous in the long run. Even though some things may get done, doing them inefficiently takes away from the enjoyment of our work, depletes our energy and momentum, and causes ineffectiveness; this is true for individuals as well as teams.
Yet a principal responsibility of managers—shareholder proxies—is to ensure the long term sustainability of the businesses entrusted to our care. We give ourselves every chance of success when we focus on efficiency first, and then effectiveness. Form before function. Quality before quantity. How before what. Efficiency results from following the correct form. Effectiveness produces an intended result. [click to continue…]
VN:F [1.8.3_1051]
Rating: 3.0/5 (2 votes cast)
Tagged as:
agile,
agile manifesto,
customer,
effectiveness,
efficiency,
leader,
product owner,
scrum,
team,
user
The last key relationship product owners need to maintain is with the team. And although their relationships with stakeholders and the market are vital in determining what gets built next, it is in the context of the relationship between product owners and the team that the work actually gets done.
The responsibilites a product owner discharges through this relationship are:
1. Direct production to meet stakeholder expectations and user needs.
2. Share the product vision with the team.
3. Identify, aggregate and prioritise features and related benefits the product will deliver to users.
4. Prepare and maintain a prioritised list of summarised and detailed work items.
5. Describe product functionality by way of user stories.
6. Negotiate to prioritise work that mitigates technical and financial risk.
7. Prioritise work that accelerates team learning.
8. Validate the product for release, including use of user testing.
9. Decide whether to ship the product.
Lighting the path
Finding the right balance between documenting and doing is an art that still causes some anxiety in the team. And clearly not all documentation is bad. I encourage product owners to use the business case and vision to create a data sheet, which can be used to articulate the broad product vision to the team on a continuing basis.
This document distills out of the vision the principal features of the product, and their related benefits, in user language. If software was still sold off-the-shelf, this would be the promotional material printed on the outside of the box.
The overview is another document I encourage product owners to produce. This artifact contains as many of the product’s features and related benefits that have been conceived at this point, in more detail than the data sheet, but still in user language.
The overview, like the data sheet, still honors the product vision. Because it communicates how the product owner has interpreted the vision, when reading the overview team members often say, “Oh, I didn’t know you meant that. We’ll have to talk it through.” Then if proposed features and benefits need to be discounted for any reason, everyone is aware of the base off of which this is being done.
Obviously sprint planning sessions, sprints, and sprint reviews are opportunities to cement good working relationships with every member of the team. The strength of these relationships will shine through in the product. Keeping the team pointed in the correct direction is facilitated through strong product owner leadership in the product backlog.
With the previous documents in place the product backlog, which is a prioritised list of tasks described as user stories, becomes a doddle to produce.
VN:F [1.8.3_1051]
Rating: 0.0/5 (0 votes cast)
Tagged as:
agile manifesto,
done,
product owner,
scrum,
team,
vision
