The upside to getting your neck wrung

September 30, 2011 Luke Walter

A common characterization of the Product Owner role is as the “single wringable neck” – the one person the business can go to when the product fails to deliver on expectations or market success. This saying encapsulates the difficulty and responsibility of the position; Few people would sign up for this, and in fact, when organizations are new to agile and particularly to Scrum, the role of Product Owner is often the most difficult to isolate and instill in only one person. Most organizations – attempting to be agile or not – fractionalize product decision making between multiple individuals, and thereby spread not only authority and ownership, but also responsibility. None of this is much good for anyone, of course; Spreading authority and ownership makes it extremely difficult to come to a solid decision, give development teams clear direction, or achieve anything like a cohesive vision – frustrating for the team and counterproductive for the organization. Spreading responsibility is even stickier: Whose fault is it when the product fails? It’s not the team’s fault – they were just following confused and ever-shifting instructions. It’s not any one product owner’s fault, either – they’re just one of many. Perversely, though, this arrangement can often be a cozy one for someone with authority.

I once had this put to me bluntly by a would-be product owner when we were discussing how much information and detail should be given the team when defining requirements. I was trying to impart the value of the more is-better approach, when he stated he wanted to provide only “Just enough detail to hold others accountable [in the event of failure], but not so much that I can be held responsible.” He appeared to be joking, but there was no denying the element of morbid truth.

If you look closely, however, it’s obvious this arrangement is an attempt to come to grips with the intrinsic unpredictability of software development, by reserving the ability to change requirements or direction mid-course. A dysfunctional and chaotically wasteful method, for sure, but such things happen when laboring under false assumptions like those embedded in waterfall.

Ironically, this ability to change course is the very raison d’être of agile development – fortified with clearly defined roles and transparency to prevent the perverse situation above. The team has the authority to say how much work it can do in a given time, and the responsibility to meet the commitments it makes. The product owner has the authority to determine what does or doesn’t get into the product (and set the priority order of what does), and the responsibility for the success or failure of those decisions. With power comes responsibility. And there’s nothing like your neck on the line to provide the motivation to perform at your best.

Previous Article
Notes from the First Jenkins User Conference
Notes from the First Jenkins User Conference

Today (Oct. 2nd), the first Jenkins User Conference happened in San Francisco. Despite a gorgeous sunny Sun...

Next Article
Subversion 1.7 Q & A, part 2

As promised, I’m continuing to answer questions posed during my recent Subversion 1.7 webinar. Today’s batc...