AgilityFeat

How do Lean principles complement and reinforce the roles in a Scrum project?  That was one question on my mind as I drove up to the Agile Leadership Network DC meeting, held in Tysons Corner.  People sometimes discuss Scrum, XP, Kanban, and Lean as competing agile methodologies instead of focusing on all the common values and principles they espouse.  So I was looking forward to Jim York’s presentation on “The Essential Product Owner: A Lean Distillation.”  Jim is a partner in FoxHedge Ltd, an agile coaching and training practice in Leesburg, and one of his specialties is training and coaching product owners.

Jim started with a definition of the Product Owner role in Scrum, paraphrased from The Scrum Primer:

The product owner is the person responsible for managing the product backlog so as to maximize the value.

One point that Jim emphasized which I really appreciated is that stories on the product backlog are “candidates for development”, and are not a commitment by the team.  The items added to a sprint backlog by the team are a commitment that the team is making to the product owner.  However, putting a story on the product backlog (which covers all stories that the product owner and the team want to do eventually), is not a commitment.  This is an area of common misunderstanding with customers.  Especially in any project where the timeline or budget for delivery is fixed, it’s crucial that the customer understand that just because you are putting an item on the backlog does not mean it will be done.

One of the most valuable points that I got out of the talk was his “York’s 80/5 Guideline for Product Owner Engagement”.  Jim described this guideline as:

The Product Owner should be able to get the team’s questions answered 80% of the time within 5 minutes.

I really like that guideline, because as Jim discussed, it can help you determine if someone is the right person to be product owner.  Your potential product owner may be the biggest expert in the company on the product, and therefore very attractive as a product owner.  But if they can’t participate in team meetings, then they won’t be able to answer your questions within 5 minutes.  On the other extreme, someone may be able to attend all your meetings and they may know all the right people to forward your question on to, but if they can’t answer enough of the questions themselves then they probably won’t be able to get 80% of the questions answered in 5 minutes.  Ideally, you want someone in between those extremes, and Jim’s guideline helps keep that in mind.

Jim spent most of the discussion focusing on the basic principles of lean, and relating those 7 principles to the role of the product owner:

1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole

You can read more about the principles of lean here, but note that the principles are worded slightly different than my notes.

For lack of time and the brevity of my notes, I can’t recount all that Jim described in his discussion, but I can assure there were many great points made.  Here is a random collection of some of the other tidbits I gleaned from his session:

• The PO can bring in other subject matter experts to help the team and answer questions, but the product owner must be empowered to keep the prioritization authority.
• Release dates are determined by the product owner in order to maximize value.
• The first question when should ask the customer when deferring commitment is “When do you need the decision made?”  Make the decision at the last responsible moment, not the last possible moment.
• Jim suggests that product owners only allow stories into a sprint if there is an eager real-world customer willing to work with the team on that feature during that sprint.
• When you have a company where one person is clearly the expert and most appropriate to be the produce owner, but they don’t have time to fill the role, they need to delegate that to someone else.  Jim suggests that the expert “publicly delegate” or “anoint” that delegate in front of the team, so that everyone knows the delegate is truly empowered to make product owner decisions for that product or sprint.  Likewise, the expert must actually let the person have that authority.
• The principle “Build quality in” necessarily is dependent on your definition of quality.  Quality should always be defined by the customer.  The team can determine how to meet that quality requirement, but it’s only the customer who can determine the acceptable level of quality.
• Keep your testing team in close contact with customers so they know what is valuable to test.  The customer may not care about all exceptions.
• The product owner should spend 80% of their time on the top 20% of the backlog.  Don’t waste time defining stories in great depth that are very low in priority.
• Product owners commonly mistake the demo/review as a one way conversation.  Teams might run the demo like: “Here’s all this great stuff, thanks for coming, bye.”  Instead, make sure it is used as an opportunity for feedback and finding out what the customer sees as useful.
• Product owners should strongly encourage visitors to the team, and have a team member tour the “information radiators” posted around the team room (burndowns, mockups, product backlogs, etc).  Having a team member give the tour gives them a chance to interact with customers and other stakeholders and test assumptions while discussing a story or priority issue with them.

All in all, it was another great meeting of ALN DC, and it’s always well worth the drive.  See you at the next meeting!

Bookmark It

Hide Sites