2/13/2009

Wringing Necks

Re: Title. Sorry, its Friday the 13th, couldn't resist!

Anyhoo...I was checking out this InfoQ post which asks the question of whether you need a single person as your "Product Owner" or it can be many. I have my opinions about the answer to that particular question, but I'll save that for another post. It's the undercurrent of that question I want to discuss now.

"One neck to wring". "One throat to choke." I've heard this and similar statements for years in reference to Product Owners (in Scrum terms that is; in XP, we may say Customer). In other words, there are people who make the statement that part of the Product Owner's role is to be the "one throat to choke", the "one neck to wring".

My take on this is similar to my feeling on the "Chickens & Pigs" thing: me don't like it, and here's a quick run-through of why.

This euphemism, at its heart, is a statement of accountability. It basically implies that the Product Owner is accountable for the outcome of your agile project, for its successes and/or for its failures. Beh, hogwash.

Let's backtrack a tad (just can't help myself ;-). I'm a believer that there exists at least these two primary degrees of agile teams:

Agile Team v1.0: practices have been installed and people are following their agile methods generally as the book tells them. They are following the mechanics, that is, but that's all. What's missing? Well, a real team. Agile Team 1.0 may not be a bad thing, it's likely to be a much better thing than to have no agile at all, but it's not the hyper-productive thing your executives were clamoring for.

Agile Team v2.0: as with v1.0, the team is following the practices, but this team is a realteam. In other words, the team is truly "self-organizing" and empowered. This team understands and manages the interpersonal aspects of good teamwork. This team truly understands that at root of success are people, and the interactions between them. This is the team that execs bought into [noun] "Agile" for; this team kicks ass.

Said another way, in Lencioni terms, the members of Agile Team 2.0 trust one another, engage in unfiltered conflict around ideas, commit to decisions and plans of actions, hold one another accountable for acting on those decisions, and focus on the achievement of collective results. Agile Team 1.0, on the other hand, does not do all of this.

Highlight: "...hold one another accountable...". There ya have it, Agile Team 2.0 is a team that shares its 'Accountability'. Each member is accountable; the developers, the testers, the CM folks, etc..., and finally, yes, the Product Owner (Customer) too. No "one neck", no "one throat", everyone.

Bottom line, if any one person holds the accountability for success/failure on your agile project, particularly if that one person is your Product Owner, you've got more to learn about how to be [adjective] agile, about how to be a team.

The good news is that you're not the best you can be, you've got room for some big improvement, how lucky!

2 comments:

You have a team of people. You hopefully are successful and have a large group of customers.

Can you expect the whole team to talk to that large customer base and still build the product? Probably not.

I believe the Product Owner IS the FINAL accountability in consolidating and prioritizing the needs of all customers and handing that to the team. Should he do this in isolation and not allow the team to interact with the customers? No! But, that role is necessary to allow the team to spend their time creating and validating, not discovering.

I agree with you that the product owner is not solely accountable for the outcome of the project. The team is. The product owner is accountable for most of the input to the project... and if they mess that up, then the team will fail. (of course if the developers create crap code, the project will fail too.)

@see <<I have my opinions about the answer to that particular question, but I'll save that for another post. >>

You've moved into that "saving for later" part.

Sure, of course, the P.O. has their part to play and things they are primarily responsible for. Most notably, having the first and last say on what's to be built as well as buffering/interfacing to real end-users/clients (if indeed that's necessary of course).

Everyone has their primary part to play.

That ain't what this post is about, its purely about the "one throat to choke" aspect. What I'm saying is that no one has the sole responsibility to accept blame for project failure or success.

Nonetheless, good points, just want to clarify you're not seeing things any different than me, least not that I can see.

Prior Art

About MB

I dig bringing great things into the world, and sharing with other people. I've been doing various forms of bad-ass software for years, and these days I work for Industrial Logic as an XP coach/trainer, as well as write weekly for InfoQ. Frankly, I love doing this stuff, and love helping others love it too.
Twitter @ mbria