In speaking with some agile teams and agile project management consultants I occasionally hear two statements that I strongly disagree with. These statements are that “the product owner is the single wringable neck on the project” or that the “product owner is the one throat to choke.” These each mean the same thing, that in an agile project, the product owner is the person ultimately responsible for the success of the project.
This is wrong, however. On an agile project—as well as in many other cases—there is no single, wringable neck. To say there is a way of releasing the rest of the team from responsibility. And this is clearly wrong.
From a manager’s perspective it can be nice to always be able to point to one person and say, “That’s who I’ll blame if things go wrong.” Howerver in agile project management the “one throat to choke” argument is false. Historically, there may be one person who takes the blame for things when they go wrong, but that doesn’t mean that person was responsible for the failure.
Take the case of a sports team. At the start of a new season, who on a sports team do we say we’ll hold responsible for winning the championship? The coach? The owner? The star player? Teams that win championships find a way to win games, no matter the circumstances. If the game plan isn’t working, the coach and players adapt. If the star player is having a bad day, someone else steps up. The whole team feels responsible for winning somehow, some way. If the team loses, it may be tempting to blame one person or another, but the team knows that each one of them is accountable for the loss. It’s never just one person’s fault. In reality, there is no single, wringable neck.
Consider a nonsports analogy. If both parents were involved in raising a child (and assuming one of them isn’t abusive or obviously negligent), which parent is the one throat to choke if a child grows up to be a convicted felon? There is a reason we call it a parental unit. Raising a child is a team effort.
The only way to ever create an environment of shared ownership and responsibility is to let go of the notion of having one throat to choke. That doesn’t mean no one is responsible. That means that on a successful team, the team members must do their part, or even go beyond a perceived role, to ensure that the team reaches its goals.
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.)
[...] was interesting reading Mike Cohn’s blog entry on The Falacy of One Throat to Choke. I remember this very phrase being used during my ScrumMaster training, saying that the Product [...]