I would personally like to see “single wringable neck” removed from all CST material. Esther Derby also has strong opinions on this as well.

Thank you for writing this.  It is about time someone did.  The whole notion of blame must go away completely for Agile to succeed.  Collective responsibility is a powerful force for greatness, but it takes a leap of faith to get there.  I hope many people read this blog and take notice.

Thank you for the well written piece! The blame mentality stifles creativity at a time when we need it most!

I couldn’t agree more. If the TEAM is self-organizing that means flat out that the team is responsible.

The “single wringable neck” is the same old fashioned business leftovers that the carrot and stick management mentality comes from and it is not only old fashioned and counter productive, but it is scientifically PROVEN to be wrong. I wish more management teams and executives would be forced to watch this http://www.ted.com/talks/dan_pink_on_motivation.html and maybe could change the organization to a more modern rewards structure. Team based rewards support agile. Those looking for a single neck to either wring or reward are missing the point.

Mike,

Great post.  I completely agree.  I’ve never liked the “one throat to choke,” mostly for how it changes everyone’s attitude.  Everyone else gets to say “Hey, not my problem, talk to the throat over there.”

Hi David, Tobias, Keith, Lanette, and Daryl—

Thanks for your agreement on this. I have to say that there have been times over the past few years while I’ve felt alone in this thinking. I knew I wasn’t but I’d hear so many people talk this way that it was discouraging. It’s great to hear agreement on this point.

And, Lanette, yes, that Ted video is a great one. I saw that one a few months ago and it was the one that finally had me look into what it would take to attend one of those conferences. If I recall anyone can pay to attend but the 2010 event was already well oversold by the time I looked.

Yep. This notion has appeal to some organizations and managers. When they like it, it’s a sign that they have a long way to go before they “get it”.

Great point, Ron! In fact that could be the litmus test for whether a management group is ready for agile!

I like to take this very carefully .
There is a difference between
A) It’s team’s responsibility- so I don’t have to worry about it
B) It’s team responsibility- so I need to do my bit to get it done

Mike,
I know you meant the latter- but I just wanted to point out the difference and that some people sadly can take refuge in the former.

Great post as usual . Thank you :)

Hi Rajiv—
Absolutely and there are teams that will take a comment like mine as to excuse to avoid responsibility. I was listening to some Simon & Garfunkel CDs this morning and since at least one of them must be a Certified ScrumMaster by now, I’ll quote them: “Still a man hears what he wants to hear and disregards the rest.”  There are definitely people who will hear only a part of this message.

Hey Mike,
Just wanted to take a moment and tell you that your quick and specific response to comments posted on your blog is much appreciated.

And I am sure I speak for the rest of your audience as well.

Thank you.

Thanks, Rajiv. I do try to respond to all the comments on here. Timeliness always depends on whether I’m with clients or in the office (which I am today). Thanks.

Magic Johnson, the ultimate Agile Team player.

In the 1980 NBA Finals against the Philadelphia 76ers, Johnson’s performance in the series-clinching sixth game was the stuff of legend. Abdul-Jabbar was sidelined with a badly sprained ankle sustained during his 40-point effort in Game 5. Enter Johnson, the 20-year-old rookie. Johnson recorded 42 points, 15 rebounds, seven assists, and three steals in a 123–107 win, while playing guard, forward, and center at different times during the game. Johnson became the only rookie to win the NBA Finals MVP award. The stunning effort exemplified his uncanny ability to do whatever the Lakers needed in order to win.

Hi Scott—
Thanks for that story. I remember that game very clearly. I grew up in LA and have always been a Lakers fan. What I always liked about Magic Johnson was how he made every player around him better—not just because of how good he was at getting the ball in their hands at the right time, but something about his competitiveness and attitude seemed to make other players elevate their games. So yes—the ultimate agile team player!

In my experience, the role of the PO is the one most difficult to establish - the “single wrenchable neck” doesn’t help.

Instead, I try to stress the point that “The PO is a pig!” (after explaining the chicken-and-pig-resturant principle). I feel the PO role should be stressed as one important to the team, and while not required to attend the Daily Scrum every day, the PO is always welcome and should, I feel, be invited to speak (briefly, of course) about what he has done since last time.

Getting the PO(s) to attend Daily Scrum on a regular basis, is surprisingly difficult to achieve…

Hi Ådne—
The PO is absolutely the most difficult role to get established.

A lot of times in classes I’ll bring up these same two points that you do: the single wringable neck and the PO as pig or chicken. I love making the point of how can anyone say the PO is the single wringable neck yet is a chicken! How would you like to be told you can’t talk at the daily scrum and then be told you’re the single wringable neck! How’s that for an inconsistency!

I tell Product Owners that I expect them to show up at some daily scrums. I tell them if they don’t, I won’t come hunt them down and make them show up (like I would a tester, let’s say). But I want them there as often as they can be.

I don’t like the term very much because of how it’s phrased.  What I explain to people is by “single wringable neck” the PO has the final say and ultimate authority over the backlog.

The team collectively is on the hook and responsible for success which means they do have input into the backlog grooming process but at the end of the day, the PO sets the priorities.

I think it largely depends on the context of the organization.  I’ve worked in environments where the term is used to ‘blame someone’ and I’ve also worked in environments where the term is to state that one person sets the priorities when the team (or product team) can’t agree.

I’m not sure why that term was created the way it was but I find people have a hard time understanding the team mentality…which of course is it’s own problem.

Hi Jason—
When I talk about responsibilities I usually make the point that “the whole team” is responsible for just about everything. But, not wanting to come across as some crappy “it-depends”-style consultant, I always augment that answer with “even though something may be a whole-team responsibility there is usually someone I’m particularly frustrated with if something isn’t happening.”

An easy example is that the team needs a good product backlog. Whose responsibility is that? The whole team. The whole team knows we need a good backlog and if we don’t have one anyone on the team could have spoken up and fixed the problem. But after I get mad at the whole team for this problem I will call the product owner aside and say something like, “Look, especially you should have known that this is a problem. Fix it!”

Whilst I agree with the sentiment of this blog, I’ve also worked on many a project where the PO was the owner in name only, and everyone knew it!

Hi Phil—
Oh, that happens a lot! I see that usually in companies where even the PO knows that he or she is too busy to be the PO but can’t let go and delegate the responsibility to someone else.

Thanks for the quick response!  I agree with that answer, I think my ‘context’ comment was more about experience regarding how I’ve seen different organizations interpret what they thought ‘single wringable neck’ meant.

I like that easy example, often I find it difficult to convey that simple message to help more structured, traditional organizations understand that it really is the whole team that is responsible.

It would be very interesting to see how this phrase can be changed in the CST material without making it sound like fluffy, “we’ll all in this together” BS, even though I do agree we really ARE in this together.

Hi Jason—
Yeah, I’ve seen the phrase be useful in some contexts. But in the vast majority it isn’t. And I do agree that we can’t just say “we’re all in this together, we’re all responsible, just play well together and make it work.” Too many people misinterpret that or hear what they want to hear.

If what we are looking for is collaboration with the customer, it seems sort of odd to use language like “one wringable neck.”

It’s the language of blame—and blame gets in the way of problem solving and creating great products. 

It’s time for that sorry phrase to go away.

Hi Esther—
Thanks for sharing your opinion. As probably the leading team-building person in agile, your opinion on this carries a lot of weight. The phrase is such a catchy one I understand why it’s popular, it’s just so detrimental though.

I agree that the blame game is detrimental to the learning game.

I also agree with Jason on the PO ultimately taking responsibility for the backlog. The whole team can share responsibility for having a good backlog but ultimately it’s a PO with real knowledge of the market, users and customers that impacts the backlog from the point of view of building the right product. The team helps but doesn’t usually have the same quantity or quality of knowledge gained out in the field (talking mostly about mass market product dev here as opposed to single customer contract work).

I don’t know about the roots of the statements neck wringing and choking statements but there’s certainly some dose of reality associated with them as you move up the org chart, especially the business/product management/marketing chart. This is especially true for product managers that have responsibility for P&L on their products or product lines. Product success from a financial standpoint isn’t always related to the quality of the product from a meeting the users needs standpoint but certainly if the product fails financially often the product manager’s neck gets wringed. If you like sports analogies (I do) this happens all the time as coaches and GMs get fired.

This also speaks somewhat to Tobais’ post on the People’s Scrum and his comments about being uneasy about aligning Scrum with CMMI and focussing on hyperproductivity & profits at the expense of the joy of work. The good companies to work for achieve a balance but at the end of the day most are in business to make money and (sports analogy again) are in competition with other companies so the balance is usually tilted towards winning the game as opposed to enjoying the game. The best do both and have winning seasons, dynasties.

Hi Phil—
Thanks for your detailed thoughts here.  Yes, there is a dose of truth to neck wringing statements. And, to be honest, if I’m the boss and a project fails miserably, I am more likely to fire the product owner than to fire all the developers. But, I still would hold developers responsible—“just not as much”, if that makes sense.

I like sports analogies, too, but know many people who don’t and they do of course get overdone. To build on your last one (about winning vs. enjoying), a huge part of enjoying the game comes from winning. So it should be possible to achieve a good balance between winning (in the market) and enjoying the work. The two can go hand-in-hand.

I read something last week that was about Harry Truman’s “The buck stops here” statement. The comment I read was about how that was 20th century thinking and wouldn’t carry us well into the 21st. I think there’s something to that.

Thanks Mike. I have seen days when they almost execute a developer just because he decided to quit and no one matched the knowledge she developed. This knowledge is unique and so hard to build as it is function of timing, attitude, character, and technicality in addition to many other unknowns. The reason this developer quits from my view is that he was alone was no peer to synergize with.
A scrum master coming from the trenches would have the sensitivity to jell the team. He, as you taught me, is the person to ensure the framework is followed. I may expand with “reasonableness” and localization to the culture.
I like your analogy to parenting. Many times the best thing I do is to be there, watch, listen and be an example.
Those with no authority, as SM, are best positioned to lead. They have the courage because they having nothing to lose! The SM dares to confront the product owner. For me, the SM is a change agent; judge; always there; people waiting for him but again with no authority! All these traits, with sensitivity, motivate the team to take collective responsibility.
Sorry for the long reply.

Mike / Esther,

We only touch the tip of the iceberg here in regards to the terminology we use to teach agile & scrum.

The Chicken & Pig joke has run its course as well, and it would be in our best interest to phase it out entirely.

I shudder to think of newly trained CSM’s going back to their teams and labeling people as chickens, pigs & single wringable necks!

David:

I don’t think the metaphors of the Chicken and Pig were meant to be used in perpetuity to berate teams and product owners but to provide an analogy to describe the importance of The Team, The Whole Team and Nothing But the Team when it comes to keeping them focused on their Sprint Goal.

I use it as an ice-breaker when explaining the rules of Scrum;  it gets mentioned once or twice to reinforce the idea that the Team is responsible for planning and execution and is distinct from other “interested parties” who are tire-kicking.

If a newly-minted SM goes to a team and in “Duck-Duck-Goose” fashion labels everyone “Chicken-Chicken-Pig”, well that’s counterproductive and proves they didn’t learn a thing.

Hi Chris—
I do something similar. I use the story but then let it go after an initial mention.

Interesting, and while I’m certainly not looking for an argument, we seem to fall back into “Is he/she a Pig or a Chicken”.. we even do so in this comment thread :)

I think the phrase “single wringable neck” came from Yahoo. I like it. A downfall of waterfall was the lack of accountability and the rise of plausible deniability. While the entire Scrum team is responsible, the Product Owner is accountable. Scrum is strong because of the clear delineation of accountability and efforts to diminish will muddy it.
Ken

I’m not sure I get the distinction there Ken.  Isn’t everyone on the team accountable in some way or another, especially for the things they commit to doing?  Or to put it another way, are we all not accountable for the things for which we are responsible?

Why for example would the PO be held accountable of they did a proper job in the PO role (e.g. identifying customer needs, creating user stories and prioritizing the backlog, and in other ways being ‘the voice of the what’) while perhaps the team over-commits and is unable to deliver on all the things they said that they would have done by the end of the sprint?

In my experience, management needs a single point of accountability. They don’t have time to sort through project members to see who did/didn’t contribute to project success (although perhaps they should as part of their job, but that’s another topic). In theory the “everyone is equally responsible” idea is great, but practically speaking, there needs to be a single accountable point.

I also think that team engagement and motivation needs to be tightly coupled to success, so I encourage management to arrange a bonus structure where all team members share equally in a successful project.  (“Successful” needs to be defined and metrics in place beforehand. If the measurement system turns out to be a poor one, people will game the system and management may not get what they want—so that becomes a kaizen moment. People will game the system in any case, so the metrics need to be set up so that after gaming, management still gets what they want.)  This bonus pool would be over and above people’s normal compensation.

I’ve thought about alternative compensation arrangements (alternative to equal divisions) but have not yet been able to convince real-life management to try them.  For example, tell the team up front “We expect all of you to participate in the project’s success, and we are going to hold the PO specifically accountable. To that end, we are establishing a $10,000 bonus pool (or whatever amount makes sense) that the PO will decide how to split up at the end of the project. The PO can keep all the bonus pool for him/herself, or divvy it up equally, or any other proportion.  Of course, the bonus pool will not be “activated” until the customer agrees they are highly satisfied.”

In my hypothetical model above, the selfish PO will not last long (in case any skeptics are thinking “If I am the PO I just take the money and run!”. It would be an interesting experiment.

I’ll start with this - I can see this being a bit contextual, based on the organization. If your entire team has expert knowledge on the domain, then this does make sense. If the Product Owner acts as the Liaison between the customer/client and the developer team, it breaks down (imo).

Fundamentally I agree with not over-emphasizing aspects of accountability that creates a “blame game” mentality.  I recommend ‘7 Habits for Highly Effective People’, ‘Five Dysfunctions of a Team’ and ‘The Wisdom of Teams’.

However, Agile/Scrum is about self-organizing teams that are highly motivated to deliver business value in the priority determined by the business (Product Owner).  There’s nothing more demoralizing than telling the entire team “you failed” because, although they worked well with the Product Owner to deliver the backlog on-time and on-budget, they delivered the wrong priority and/or feature set.  You can’t hold someone accountable for something they’re not equipped to succeed in.

Of course the entire team should help the Product Owner if they’re in a place to, but ultimately just as developers are *responsible* for production-ready deliverables, and the scrum master is responsible for removing blocks and keeping the focus on the Sprint Goal and enable production-ready deliverables, the Product Owner is responsible to make sure the product backlog represents the business value (product/marketing research, etc.). 

So although I feel you need an accountable Product Owner, that individual could have a team responsible to him/her for building the priority of features (usability studies, product and market research, etc.).  However, Product Owner “by committee” risks slowing down every iteration (Sprint Planning, the back-and-forth discussions and questions, demos and acceptance-testing, etc.).

If the product owner is accountable, that means he is the one who have authority in the project. Then, he might choose to replace or even rid off the scrum master, if he wants. The product owner could do that just because scrum master is doing her job in maintaining the cadence of the project.

I believe that the sponsor of the project should be the only accountable person. The sponsor can fire the scrum master because he is not implementing scrum in acceptable way, but NOT because he chases the product owner to do his job.

Hi Sameh—
I agree with your view of the ScrumMaster—-definitely a change agent. Thinking of “parent” and “change agent” in the same reply is interesting because parents are also change agents. We all know a child will grow up but will the child up grow up happy, healthy, productive, etc. Perhaps we can think of the parent as the change agent nudging children towards what is (likely) best for them.

Hi David—
While chicken / pig stories can be useful, any story like that has its shortcomings in reality at some point. I have always believed the PO is a committed team member but that goes back to how I started doing Scrum. Even in the beginning for me there was never an us/them distinction between product owner and team. I suspect this is because when I started with Scrum I was managing teams, not consulting and I would have fired people who created an us/them culture.

I like to put the chicken/pig story aside by asking people (especially parents) to really think about what the chicken is giving up—her kids! I think anyone who gives up her kids is committed to the breakfast. :)  The real person who can’t talk at a daily scrum? That’s the cow—-the cow just gives some milk to be part of the breakfast. Don’t ask me who the cow is on the team because I have no idea. As for me, though, Scrum being a “whole team” process means I want the whole team participating.

Hi Ken—
I’ve heard you attribute the “one throat to choke” saying to Yahoo but I consulted there for three years and never heard it. So I suspect like most things, it was part of a sub-team culture rather than across all of Yahoo.

I’ve never understood the distinction between accountable and responsible. I’ve heard you and others use them to mean different things but I can never remember what the distinction is and my simple computer-based dictionary just listed them as synonyms. I doubt that semantics will solve anything if there really is a difference. That would be like the team I encountered who decided only programmers could call a feature “done,” only the testers could call it “completed” and only the product owner could call if “finished.”  Nice enough in theory, I guess, but no one could remember the difference and programmers still said things like, “I stayed last night and finished the such-and-such feature.”

I can agree with you that a big cause of waterfall failures is the plausible deniability of the product manager. But I think much of that was because of the introduction of the project manager role. A traditional product manager could say, “Yes, we failed but if they had built everything I asked for, the project would have been successful. I told the project manager I needed it all.” On a Scrum project we of course acknowledge the constant swirl of new information and scope/schedule tradeoff decisions cannot be made all at once, upfront. The product owner needs to remain engaged and make those but the team is responsible/accountable for contributing information to those decisions.

Hi Steve—
Incentives, financial and otherwise, can play a big role in how people respond to what they are told they’ll be held accountable/responsible for. We all know how those incentives can work out well or poorly. I worked with a team a few years back that was offered a bonus almost exactly like you describe and it was sizable.

It wasn’t the product owner who would allocate it to individuals. The team was told to figure it out. The team was given a pile of cash and told to figure out how to split it up. They thought about seniority, as a percentage of salary, votes by team members, etc. In the end, they gave the bonus back to the company saying that anything they did with it would cause dissension among team members. They didn’t want that. I was very proud to have worked with that team.

Mike - lol, very funny (chickens, pigs and now cows?!?). Before any more farm animals get introduced, and regardless of the story we use, Scrum is powerful because the people who are held accountable have the authority to make decisions (“skin in the game” or “skin in the skillet”).  We avoid the “Well, I never really bought in to what the Lead/Manager said, and I knew it would fail” mentality.

Imagine your raise/bonus being based on another department’s budget; you have no control or influence on the budget. 

And just because the same people on one team have different “roles”, doesn’t mean it has to be an “us vs. them” mentality. “Blame” is a function of team dynamics (or team dysfunctions), but it is fair to say “We are team, and here are our roles”.

Your thoughts?

Hi Matthew—
I very much want individuals on a team to be aware of the unique aspects of each’s role. But a project succeeds or fails together. Anything working against that is sub-optimal. Is every organization ready for shared responsibility? Of course not. But organizations that are capable of it should act that. Those that aren’t should take initial steps in that direction—and an initial step often is stricter individual responsibility (“I’ll choke you if this goes wrong”). I’ve said before I’m OK starting there but it’s hardly a good ending point for teams that strive to be the best.

I don’t know if you follow VersionOne blog, but last friday they had a post about the “top three roadblocks to delivery”, citing “The Product Owner or Product Ownership Cloud lacks the Ability to Precisely Slice & Dice Information From a Traditional Project Management Document Into Meaningful User Stories” as the number one problem to successful agile delivery. ( http://blog.versionone.com/blog/versionone/0/0/special-delivery-delivering-agile-projects )

I noticed the term “Product Ownership Cloud” (they used to call it “Product Owner Team” or “Product Owner Committee but I guess “Cloud” is the current fad…) - while I am opposed to the wringing of necks in general, calling something a “cloud” makes it difficult to hold anyone responsible/accountable…

Hi Ådne—
I don’t follow their blog regularly but do see it occasionally. I hadn’t seen this one. I don’t think “product owner cloud” is going to become part of my standard vocabulary. Although it might be fun to refer to some Product Owner teams as cumulus and others as nimbus or cirrus and some of those other words I should remember from science class oh-so-long ago.

Here are a couple of ways to view the subtle difference between being “held” accountable and “taking” responsibility.

A teacher is “held” accountable for creating assignments designed to help students learn while the student “takes” on the responsible for completing an assignment.

The Product Owner is “held” accountable for having itemized the stories, priority and points that make up the Product Backlog while the team “takes” on the responsibility for developing, delivering and deploying the stories.

Therefore, as Ken points out, when using Scrum the Scrum team is responsible and the Product Owner is accountable.

As for the use of the phrase “one throat to chock” or “single wringable neck” if one takes either of these 2 phases too literally they may send the wrong message, are often misinterpreted and may be interpreted as offensive.

Hi Russell—
I’ve heard variations of this distinction before. Often it is something like “accountability comes from someone else” (e.g., you are “held accountable” as in your example) whereas responsibility is something the team accepts.

One problem with this is that the distinction is awfully fine. Second, I’m not sure it works. I could, for example, rephrase what you have above as “the team is accountable to company leadership for delivering a high-quality product.” (Or anything similar.) The distinction if it exists (this way) is awfully precise for us to hang our hats on in justifying calling someone a single wringable neck.

Maybe I can email Grammar Girl (my hero) to clarify.

Could not agree with you more!

Thanks Mike.

Hi Mike,

Is it not the responsibility of the Project Owner to ensure that the entire team is in face doing it’s part?  Thus, if the team fails because members of the team were not doing their part, the PO can be held responsible as it is his responsibility to ensure this happens?

As others have said, accountability = “individuals taking responsibility” is good, “creating plausible deniability” is bad.
It all depends on whether you’re playing to win or playing not to lose, as Kent Beck put it.  And whether you define winning or losing in terms of the team or in terms of yourself.  Ask yourself these questions; be honest in your answers, and be willing to change.  Ask yourself how the PO /PM / powers that be would answer the question; be fair, and be willing to move on (or stick your neck out) if you don’t like the answers.  (Disclaimer: I’m all for blooming where you’re planted and being a change agent.  But don’t prolong your exposure to a toxic environment either; life is too short.)

Thank you Mike for starting this blog!

I am interested in knowing how the dynamics of POs (yes, multiple POs) play out when the POs have orthogonal backlogs. One is customer focused, the other would be technology focused. The goal is to ship new features while keeping our technology current.

Disagreeing just slightly:  I have found the “one throat to choke” to be very effective in my current consulting situation.  This particular firm is mired deeply in a stew of hyper-over-matrix, management by consensus, right of infinite appeal, and of course, a process heavy waterfall that makes even hardened Agile consultants cry.

I have been very clear about the distinction between Pig & Chicken, which translates here into accountability of the Team to deliver upon their commitments, versus PO and the “single throat”.  What that represents here is that one person owns establishing decisions as they relate to the project’s scope and priorities.  In fact, we have a half dozen POs which each own various MMFs, and there is no “Uber PO” that oversees the prioritization cross MMF.  So in this case, it is the collection of 6 POs who represent a Steering Committee.  However, each independently and singularly owns their MMFs.

This is important because what happens in this sort of organization is someone pops up 2 months after a MMF is delivered and starts playing the “right of infinite appeal” game.  Here is where empowering that single PO over that function area has tremendous benefit. 

I guess I see the original concept as perhaps a legacy of what the folks were facing as they first started driving Agile change into these sorts of companies.

I might be able to help on the accountability vs responsibility front.  One thing I’ve noticed in talks about Scrum is a tendency to look at the members of the team as the only part of the organization.  As has been pointed out, Scrum applies responsibility to the entire team.  Accountability isn’t relevant to Scrum, it’s tied to the organization’s hierarchy. 

Your Product Owner is held accountable by their boss for whatever product(s) they were assigned to own.  That boss is outside of the Scrum framework.  If the product is failing, the Product Owner is the one who explains why to the people above them and the Product Owner is the one expected to fix the problem. A programmer is held accountable by their supervisor for showing up on time, actually performing the job they were hired for, etc.  That supervisor may or may not also have a role within the Scrum team.

Just as the entire team is resposible for the project, the entire company is responsible for the success of the company.  However, if something is wrong with one product, you don’t hold a company-wide meeting to discuss why.  The king of the castle asks his appropriate subordinate, who asks his appropriate subordinate, etc, etc, all the way down to your Product Owner, who sits down with the team and figures out the answer (or already knows due to activities within the Scrum process) and passes it back up his chain of accountability.

In short, in Scrum, everyone is responsible and accountability is not relevant.

Sorry if that was a bit of a ramble.

You people are crazy.

What if your check didn’t go through? Or if your salary was cut? Would it be okay for the accountin gteam to talk about not assigning blame, or Results isn’t the point? It’s stuff like this that makes the rest of the world think us engineers are out of touch and naive.

Look - in order for a business to succeed, it needs to make a product. The product needs to have a certain number of features, it needs to work, it needs to be done by some particular date or another. If not, the business can’t succeed. If it doesn’t exceed, PEOPLE DON’T GET PAID. All ofthis flowery “we’re all a team” business is fine, but it falls apart when the money stops. It reflects an unrealistic perspective on sotfware development.

My perspective might come from my background - I’m an MIT engineer who has started a company. I appreciate and respect the complexity of software development, and the risks inherent in the waterfall method. However, the landlord doesn’t take story cards as payment, and neither does your mortgage company. RESULTS MATTER. EXECUTION MATTERS.

And by the way - when a sports team starts doing poorly, the coach gets fired. Period. SOMEONE HAS TO BE RESPONSIBLE, ALWAYS. Why? Because prediticability is critical. Revenue needs to e predictable so payments to YOU are predictiable (which, ironically, you demand). The predictibility of revenue is directly tied to the predictability of software development! Saying otherwise makes people think we don’t get it!

Mike,
Great stuff and you have definitely given me a good reason never to talk about “the single wringable neck” again. My interpretation of this phrase was different again, I always used it to emphasise the importance of the PO owning their backlog and listening to the people around them (clients, team, environment).
I love the idea catchy phrase to start a conversation and make things easier to remember however your article and the comments above have illustrated that any catchy phrase is open to a vast array of interpretation and abuse (unintentional or otherwise).

First let me say how much I enjoy reading this blog. It is always entertaining and educational.

I agree that thinking like “single throat to choke” thinking can often be counter productive to agile organizations because it can actually errode collaboration within a Scrum team if the PO is that person. 

Funny thing is that for organizations that actually talk about it, from my experience, it is rare to see it acted upon in our overly politically correct business climate. 

As soon as you want to do a retrospective type review of what happened, the politically savvy pull out the trump card seems to end any investigation that could help avoid a similar issue in the future.

That card is “Well that is in the past, we are where we are now and we need to deal with it”  and then the fait accompli ...“You’re not being a team player” :-)

Finding ways to enlighten folks in environments like I describe is a real change management challenge.  Any suggestions?

My 2 cents: During a ‘Contracting’ open space with Mikael Lundgren in Stockholm, we noted that we still need to lobby more with our customer’s purchasing department to get from accountability to responsibility (and I might add now, real business benefit). So in a sense the product owner is a proxy fighting the accountability issues, whereas involved people in general strive for sustainable benefits on either sides (supplier and consumer). btw - a leo.org thread puts the following example for responsible: “termites were responsible for the damage” - if you invert the sentence you may get “people will be responsible for success”. Thanks for this rich blog, Mike.

Mike,

Over the years you have brought great insight to the Agile methodology, and we all appriciate that effort.  Except in this case.  I agree greatly with the statement “the product owner is the single wringable neck” should the product be wrong in the customers eyes.  Here is why.  As the Product Owner is the liason between the team and the customer/end user it is the P.O.‘s job to be correct in articulating what is desired by the customer.  If the P.O. is wrong then it is not the fault of the team, this is the fault of the P.O. 

Now when you bring management into the picture and they are looking as to what part of the process broke down, then you can look at the team, the SCRUM Master, the PO, etc.  However these people are not to blame shouldthe customer reject the product.

Sorry Mike I just disagree with you on this one.

Bob Small

If a member of your team is not pulling their weight, it’s not really a Scrum problem.  If Bob in the corner plays video games all day instead of working, handle it like any personnel issue.  If he gets to stay and continue goofing off, you’re better off looking for a better company, especially if it’s a pervasive problem.  If he’s let go, you can mention in a retrospective that X amount of the available effort wasn’t really present which impacted what got done.  Either way, you avoid any political issues and move on in a constructive manner.

I may be making some assumptions here.

Mike, would you say that a Product Owner has a function within Scrum, but also a function outside of Scrum?  Seems to me that the Product Owner’s responsibilities outside of Scrum could certainly get his neck wrung, but his functions within Scrum would not.  And so when consulting on Agile/Scrum, one should either omit the concept or clarify that separation.

I think this phrase is a terrible of dysfunctional management.

Andrew Ryan says “RESULTS MATTER. EXECUTION MATTERS.” - and that’s very true. However if a team doesn’t deliver a working product in a reasonable timeframe, whose “accountability” is that? I think it’s way past the “team” level. It’s the MANAGEMENT. So if Andrew’s company doesn’t get to “done” (i.e. release) I will blame Andrew’s company.

Here’s the thing, someone else said above -  “In my experience, management needs a single point of accountability.” and the thing is THAT SINGLE POINT IS THE MANAGEMENT ITSELF. That’s what being a manager is about. Leading.

It’s not fault of the the team, or the PO, or the SM, truly, if your company doesn’t get to delivery Mr Manager, it is YOUR FAULT. You allowed the crappy culture to develop, or sustain, you allowed the expectations to be unreasonable, you are the one who didn’t listen to advice, or seek it out in the first place, you are the one who didn’t get their business plan sorted out to make sure you had budget to survive for long enough to get to execution and YOU are the one who didn’t make sure the team got to execution. The Buck Stops Here and “here” is the desk of the CEO. Even if you got a team of lazy, ignorant layabout that’s STILL YOUR FAULT because you hired them, or allowed them to continue to be layabouts without doing something about it.

It’s not SUCCEED OR FAIL it’s SUCCEED OR LEARN TO SUCCEED and the Management is the one responsible to make sure that’s the way the organisation learns to function at all levels.

Anything less is still that small-minded mentality of “I would have been a business success if only YOU PEOPLE had worked harder” just scaled up to large organisations.

So yeah, great post Mike.

Hi Mike,

Great post!

As an aside, the term “parental unit” is an allusion to the old Coneheads skit from Saturday Night Live, and it referred to an individual parent, not to two parents acting as a “unit.” (The coneheads regularly referred to one another and to other individuals as “units.”)

However, in principle I agree with the idea: a functioning team works together to nurture a product just like a functioning family works together to nurture a child.

Wringing necks, besides being entirely immoral, unethical, and illegal, will not get you anywhere as a team. The right thing to do is to get regular feedback from real users and work together as a team to deliver value.

The product owner, by having a singular focus on business value and priorities, plays an important part in achieving that, but he cannot and should not do it alone. Therefore, he cannot and should not be held solely accountable.

Whoa. I wonder where this post got picked up that we had so many new comments on it today. It’s good to see such interest in this topic. I’ll try to reply to some of the issues that came up and were addressed to me but so many were just great discussion among people here, which I love to read.

Shawn: Yes, I think the PO is responsible (accountable) for making sure the team does its part. And if team members don’t, in some cases I would be mad at the PO. In other cases, though, I’d look at the situation and might think that the PO had done everything I could reasonable expect and the team was just a bunch of slugs who underperformed. It’s rarely as easy as saying there’s one person I’ll be mad at / fire / hold accountable if things go wrong.

Randy: Absolutely—sometimes saying “you’re the one throat to choke” is necessary. Some cultures have gone so far to the plausible deniability end of the spectrum that this message is needed. Hopefully after a few projects (months or years, perhaps) that culture has changed and the message can be made more inclusive.

Matt—Yes, I think your clarification helps. If I’m the boss and the project fails, I am going to want to talk (at least first) to my main interface into the project, which is probably the product owner. The product owner is the boss’s lens into the project.

Andrew—I’m sorry you feel we are (all?) crazy. To use your landlord analogy, though, does the landlord care when he comes to the door and I say “My wife has her half of the rent. I’m sorry but I don’t have my half”? No, he doesn’t. The team (me and my wife) have to pay that bill collectively. As for sports teams firing the coach: How often does that work? I saw an article recently on ESPN I think about coaches in jeopardy and how rarely changing the person in charge results in a dramatic turnaround. If the team’s players aren’t changed, it’s unlikely there will be a dramatic turnaround in that team.

Mike Lowery: I don’t suggest never using the phrase. There will be times it needs to be said but those should really only be in dysfunctional cultures that aren’t ready for a “we’re all in this together” message. Say that at the wrong time to the wrong team in the wrong culture and will come off as new-age, flowery BS. I’m with you on the last part: mostly be aware of how the message can be interpreted and know the drawbacks to any message.

Mike DePaoli—Wow, I’m with you on the issue of how rarely this is acted on. One of my angriest moments was a project that was essentially successful but the team was about 2 weeks late (on I think a 10-month deliverable with of course more than 2 weeks of scope creep). The product owner was given a 2-week trip to Hawaii on the company dime for delivering the project. The team was given a tongue-lashing by the CEO for being late. I read a little blurb in Harvard Business Review about two years that said something like only 20% of projects are ever assessed for whether they met financial goals. It seems that all projects are assessed for whether the team met the deadlines but very, very few are looked at a year later to see if they met the financial projections and such.

Thoralf—I love the “termites were responsible for the damage.” I bet the homeowner was accountable!

Bob—I’m glad you disagree with me occasionally. Life wouldn’t be fun if we always agreed. The only one I want to agree with me all the time is my wife. (And I can say that because she doesn’t read this blog; otherwise she’d kill me!)  Joking aside: I agree that in the customer’s eyes, the product owner should be the single wringable neck. If I hire you to build a product for me and I never see the team (totally reasonable assumption) you are the project in my eyes. If it fails, I am furious at you. But my expectation would be that the team knows that you and they will succeed or fail together.

Matt—Yes, the product owner has responsibilities both inside and outside the team. This is part of what makes the product job the hardest one in Scrum, in my opinion.

Scot—I like your views on management accountability. To think about the “the buck stops here” attitude consider two cases. One where some manager puts a sign saying that on her own desk. Then another where her boss walks in and says “Amanda, the buck stops with you!” Those are very different. One is the person being very clear they are accepting responsibility for whatever happens. The other is the person being told “you’re accountable, no matter what.” I’d love to work on a team (software development team or management team) that said “the buck stops with us.” I wouldn’t want to work on a team where my boss told me the buck stops with me no matter what.

Adam—Do you think with a last name of Cohn (pronounced “Cone”) and going to high school in the 1970s, I was unfamiliar with the Coneheads? Oh that was a nickname I heard a lot! But, I do think you’re right—I think the etymology of “parental unit” does originate with Saturday Night Live. But I just did some Google searches now and common usage today is about the parent or parents raising a child. I saw references to “mixed-race parental unit,” “mixed-religion parental unit” and so on. But thanks for pointing this out and reminding how good that show was way back when. I still make a point of eating at the Billy Goat when in Chicago, where it is still “No Pepsi. Coke.”

Your interpretation of the “one throat to choke” concept is very different from mine. My interpretation is that the Product Owner is responsible for achieving the Return on Investment (ROI) for the project. The ROI of the project is achieved by the implementing features that either decrease costs or drive revenue enhancements.

The Product Owner maintains the product backlog and sets priority for what feature to implement and when. Of course they shouldn’t make these decisions in a vacuum, but they are the final say when it comes to what to implement when. I recently wrote a Blog posting on this topic [link removed as it no longer worked]

In my experience the Product Owner is responsible for making the case for features that will bring the highest business value (aka highest ROI for the company). If the Product Owner isn’t making wise choices about priority then the ROI for the product may not materialize. In this case, they alone are the “single throat to choke” for not achieving the financial goals of the project.

The majority of the teams that I have worked with haven’t applied this concept as a blanket statement as you describe in your posting.  I do agree that the Product Owner shouldn’t be the scapegoat for all project failures. To me a healthy Scrum team (Product Owner and ScrumMaster included) should succeed or fail as one unified entity.

Mike, the post was featured on a VersionOne Newsletter email.

Scot, believe it or not, it’s not always (entirely?) management’s fault.  I place I worked at this summer (and left due to a dislike of their culture) apparently had a fiasco after I left where a major product turned out to be unusable because of a major flaw in the system.  Apparently multiple members of the team knew this and kept it secret until near the end of the project.  Another person on the team discovered it and raised alarms.  The others managed to get the whistleblower fired somehow, but when management found out, they axed the entire team.

Sure, you could argue that “management fostered a culture that allowed this to happen” but you’d have to micromanage the team to be sure of such things not happening.  I’ve yet to meet a developer who likes to be micromanaged, not to mention that it slows everything down hugely if you don’t trust your developers (or anyone) to do their jobs.

Ahh, Matt. The VersionOne email explains the second round of interest in this post. I saw that I have something from them but I hadn’t opened it yet. Thanks.

I think this is too PollyAnnish. The reality is that business works when people are accountable for the results of their team. Product Managers should be the single throat to choke and this is only a problem if they cannot make decisions that effect the outcome before it occurs, i.e. if they cannot resolve team problems, rank the backlog without intervention, hold non-performers accountable to their manager, etc.
For market-driven products, we need accountable product owners.

Hmm, I never realized that the choke neck/break leg statement was actually taken so literally. It’s not about accountability or responsibility at all, whoever had that mad idea? :-)

The word “single” is actually the most important one here. Like with so many things, Scrum forces dialog, puts pressure on the system, makes you face reality and forces you to make the hard choices.

One of the hard choices to make is about prioritization. The team or teams have a finite capacity, and you can’t get away with not making a choice and saying “do it all!” or somehow overloading the team with what I call “death by five-minute emails”, where a team just can’t go forward because of all of the urgent-but-unimportant crap thrown their way. The whole choke thing should be interpreted as “the focal point of prioritization” or “the eye of the needle”.

An organization is not allowed to say “everything is important” and throw everything at the team, but have to explicitly address the confrontation of different needs and wishes against each other. *The PO serves as that focal point.*

I’ve always explained the statement this way to whomever I’ve coached or taught, but okay, if we need another statement, why not use “the single focal point of priorities”?

Serge, I think you’re blending what they were talking about with the concept of a “choke point”.

Hi Mike,

Thanks for stirring the pot on a really important topic. I’ve spent the last 20 years trying to understand practical individual, team, and organizational issues of accountability and responsibility; I think what I’ve learned can be additive here.

First, I would guess that the “one throat” vernacular comes from the traditional management practice often called “single point accountability.” In brief, the idea is that delegating and managing accountbilities is the single most important tool, building block, and control mechanism in an organization. The assumption behind the single point notion is that if no one individual is held to account then no one will take ownership (hold on to this idea as below I will argue that “managing accountability” and “taking responsibility” are not the same at all, and, that it is more than semantics). During my career I’ve noticed the more an organization runs on fear, control, and manipulation, the more this single-point-accountability principle is cited as important.

According to a prominent researcher whose work I admire, managing accountability is the only reason for hierarchy. There is one head (CEO, Director General, etc.) who is “held to account” for 100% of the operations and results of the organization. That person frequently is rewarded for success or pays the price for failure. That person also divides his/her accountability into parts and delegates each to a subordinate and holds them to account. This activity cascades through the organization.

Accountability Does Not Equal Responsibility

As you stated above Mike, the terms Accountability and Responsibility are used interchangeably. That’s okay. The issue though is that there are two very different meanings that can be conveyed by either word. For purposes of making the distinction, I will use Accountability for one meaning, and Responsibility for the other (though individual uses vary and I’m not here to nitpick about that).

Accountability is literally “the ability to account for.” It is a story about why or how results did or did not occur. And it’s a complex relationship process of trying to connect the future and the past with prediction, negotiation, cooperation, and interpretation. The way we manage accountability is through the process of negotiating and following up on agreements (i.e., role descriptions and job duties). We call this by lots of names: job design, role description, delegation, accountability management, performance management, one throat to choke, etc.

But here is the kicker: Whether or not you are held to account is not up to you. It is up to someone on the other side of the agreement. We’ve all had the experience of being held to account for something that we did not think we deserved. And we’ve all likely had the experience of not being held to account for good work that no-one noticed. So I like to think of accountability as “external” to me (since so much of it depends on what my management—or customer, parent, spouse, teammate—perceives and does).

As important as it is, there is a dearth of research on accountability. Management researchers tend to avoid it like the plague. Most of what is published is by consultants and successful former executives. I recommend reading Elliot Jaques who spent 50 years discerning the universal laws of hierarchy (most organizations violate these without realizing the systemic problems they unleash). See:
http://en.wikipedia.org/wiki/Elliott_Jaques

Also, read some of the PDF downloads here:
http://www.osun.org/Elliott+Jaques-pdf.html

On the other hand, Responsibility is “the ability to respond.” It is a feeling of ownership. That’s right, a feeling. Responsibility is always in the present and has to do with what happens when things don’t go as planned. The question is, will you respond resourcefully or won’t you?

We may feel a sense of ownership for our job role and duties or we may not. Thus responsibility is subjective. It is completely internal and can not be managed or controlled (though it can be inspired). That is, you can’t make anyone take responsibility (feel a sense of ownership) for their situation.

More than that, Responsibility is transient—it comes and goes for all of us. We are hardwired to avoid owning it as a first response when things go wrong, and things go wrong everyday.

In my experience Responsibility (the ability to respond) always trumps Accountability (the ability to account for). The organizational problem is that you cannot manage feelings, but you can manage accountabilities, albeit poorly much of the time.

This is why we all prefer to work with others who take responsibility. It is also why we want to work on teams that share responsibility, not to diffuse and hide from accountability, but so that someone will respond to what they see needs to be done in support of the project. Needless to say, it is also why truly responsible leadership is important, as is culture, and self-organizing teams.

I’ve found well-intended leaders and professionals enjoy learning the differences I attempted to describe above. They can translate this information into higher performance and greater humanity at work.

Here are some links to more information at my site on this topic.

http://www.christopheravery.com/blog/the-difference-between-accountability-and-responsibility/

http://www.christopheravery.com/blog/team-rewards/

I’d be happy to offer a tele-seminar or webinar on this topic for agile teams, leaders, and coaches. If you would like that, let me know.

http://www.christopheravery.com/contact

Hi Christopher—
It’s great to see you here. I’ve been a fan of yours since you gave the keynote at XP Agile Universe in 2004. I appreciate your insightful comments above. I’d recommend everyone interested in this topic check out your book. I’d forgotten how germane the title is to this post. For those who don’t know, the book is Teamwork Is An Individual Skill: Getting Your Work Done When Sharing Responsibility.

Thanks to for the links Elliot Jaques. I’m off to check those out now.

Mike
I agree with you.  It is time to retire the phrase, but not the notion that the Product Owner (and the ensemble cast supporting the role) have domain over ‘what’ the product does to add value.  Accordingly the team has domain over ‘how’ to deliver the value asked for.

Great book, even after several passes through because I realized I missed something!

Regards.

Hi Mike—
Yes, the “what/how” distinction between the product owner and team is a valid.

I’m glad you enjoyed the Succeeding with Agile book. Thanks for letting me know! I also appreciate that you wrote an Amazon review for it. Thanks!