Monthly Archives: January 2009

3 Keys to Effective Product Ownership

In agile and Scrum, the Product Owner is, by far, the most demanding role. The PO acts as a go-between for communication between the customer and the development team, but, if the whole project goes to the dogs, he or she is the individual responsible for the disaster. But that responsibility doesnÂ’t necessarily mean that the PO is in complete command of every situation. Sometimes, POs need help from the developers on the team as well as the ScrumMaster to provide them with the kind of information they need to succeed.

For instance, the Product Owner must possess the ability to prioritize. If a member of the development team goes to the PO to ask which features of a given product are most vital, an answer like “They’re all equally important” doesn’t help anybody. Teams need to know what functionality is most essential to the product, so they can pursue that goal as soon as possible.

A Product Owner must be able to articulate requirements—not “sketch out,” not “summarize,” but articulate. Since the development team depends on the PO to relay information, his or her ability to do so in a way that accurately conveys the customer’s vision is crucial to the success of the project.

Likewise, a Product Owner also needs to be equally adept at stepping back and analyzing the big picture. This perspective is what allows release planning, strategic initiatives, and more. If a Product Owner cannot operate at that level, then he or she may not be cut out for the role.

How can team members help ensure that a Product Owner is doing all of these things? By asking questions. When gathering requirements, developers should work to understand the customer vision by asking the Product Owner to share what he knows. Over time, developers will cultivate skills to help draw out information from the Product Owner. For instance, when attempting to assign a priority to a particular story, a developer may want to ask the PO about its importance in relation to several other stories, in order to softly assemble a hierarchy. Through these conversations, developers can train their Product Owner about what kind of information is most valuable to successful development.

Do You Know Agile as Well as You Think You Do?

Over at the blog Business Analyst Diaries, I came across a this post asking readers what their elevator pitch for agile would sound like. ItÂ’s a fun post, with a few stabs included in his original post and at least one game commenter chiming in, but I think it speaks to a few critical issues for the success of agile. First of all, agile is still neither widely nor clearly understood. And secondly, when it remains vaguely defined or misunderstood, its value isnÂ’t obvious to those who need it most. Hence thereÂ’s a need for a succinct sales pitch.

Let’s start with that first one. Why does agile’s meaning remains so elusive for so many people? In part, I’d argue that’s because agile has no clear definition. It’s an umbrella term applied to many concretely defined methods and frameworks, including XP, DSDM, and Scrum. While those subsets of agile all contain specific principles and processes, agile is simply shorthand for development that uses repeatable iterations to frequently inspect progress and adapt to it, an emphasis on teamwork and self-organization, and an approach to development that closely involves the customer. Still, even that definition leaves out some significant distinctions among the various methods. A better elevator speech would likely focus on what agile techniques yield: Namely, increased product quality, reduced cycle time, and customers who get the products they wanted. Still, that doesn’t really identify how these methods do what they do. For me, the solution is to narrow the scope to what you really want to “sell.” If it’s XP, focus on how XP’s engineering practices enable teams to control costs through a strict attention to quality. If it’s Scrum, talk about how its unique emphasis on self-organization empowers teams to make tough decisions that they believe in. But if you still want to give an elevator speech on agile, you might discover you’re not exactly sure what it is you’re selling…