Scrum Product Ownership

by Charl Dreyer on August 31, 2009 · 2 comments

in Roles

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

Bookmark and Share
VN:F [1.8.3_1051]
Rating: 3.0/5 (2 votes cast)

Team Players

by Charl Dreyer on August 21, 2009 · 1 comment

in Documents, Roles

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.

Bookmark and Share
VN:F [1.8.3_1051]
Rating: 0.0/5 (0 votes cast)

Doing the Business

by Charl DreyerAugust 18, 2009 Documents
Thumbnail image for Doing the Business

Having something sensible to say to busy executives who have committed their valuable time means that beforehand product owners should have mapped their products’ ‘DNA’ to provide a framework to discuss current and future product initiatives. It may prove handy to refer to a conceptual model, and a trading community model, during these stakeholder sessions as well.

2 comments Read the full article →

What’s in a Word?

by Charl DreyerAugust 10, 2009 Individuals and Interactions
Thumbnail image for What’s in a Word?

As a principle, bureaucracy has been tremendously successful over thousands of years, evidenced by the fact that it is the mother of all incumbent systems today. During the 17th century bureaucracy, or ‘rule by office’ became an effective counter measure to governments being staffed by friends, relatives, or those of a particular social or ethnic group.

1 comment Read the full article →

Raising The Bar?

by Charl DreyerJuly 28, 2009 Polls
Thumbnail image for Raising The Bar?

“The Agile Manifesto’s values have been tremendously successful at providing the software industry with similar benefits that Lean Manufacturing furnished for Toyota. Unfortunately, we’ve also learned that too many individuals and shops have given Agile software sevelopment a bad name by using it as a fig leaf to hide behind delivering crappy software and calling it agile, further setting back software engineering as a mature discipline,” say Rick Garibay.

4 comments Read the full article →

The Way It Works

by Charl DreyerJuly 9, 2009 Customer Collaboration
Thumbnail image for The Way It Works

Good customer service is a valuable asset, especially when upholding the Agile Manifesto’s value of collaborating with customers over product development. It’s wise for Agile teams to bear in mind that a good reputation for service is built up over many years of effort.

0 comments Read the full article →

Shark Swallows Woman

by Charl DreyerJuly 2, 2009 Responding to Change
Thumbnail image for Shark Swallows Woman

If Scrum’s review sessions are approached with honest and open minds, and without recrimination, they are powerful to effect the kind of change you need to become continuous improvers of your business.

2 comments Read the full article →

Scrum et al

by Charl DreyerJune 4, 2009 Agile.tv
Thumbnail image for Scrum et al

Scrum is an amazingly simple process that causes many changes in an organisation when it is implemented. And because it really is simple common sense, many people try to add complexity to it. So it’s beneficial to hear again the idea from first principles.

0 comments Read the full article →

Working Software over Comprehensive Documentation

by Charl DreyerJune 2, 2009 Documents
Thumbnail image for Working Software over Comprehensive Documentation

The Agile Manifesto values working software over comprehensive documentation. In agile projects working software is the ultimate quantification of your project’s status. This may take some getting used to. The agile leader though, may be more interested in artifacts describing the project’s functional effectiveness: The ‘why’ of the business. This is because you are responsible for the software beyond its manufacture: Why you invested in it, and why it complements your broader business plan.

0 comments Read the full article →