Glen Alleman describes the business management process they use - called Afterburner - and its reliance on personal accountability for success. Glen then describes his discomfort with the idea of team accountability instead of having one person be accountable. According to this month's video newsletter for Afternburner, in the four step process: 1) plan, 2) brief, 3) execute, 4) debrief, the debriefing cannot be done effectively if we cannot ask the question "who was responsible for the failure?".
Glen questions the effectiveness of having a team accountable and what that means when there is no single point that is responsible for success or failure. Andrew Joiner posted a response:
Nowhere does Scrum or Agile say that an individual is not accountable. Of course they are; they make a commitment to the team whenever they take on a task during a sprint, and they are held accountable by the team to completing that task, with or without assistance.
Furthermore, the team as a whole is being held accountable for delivering what they said they would at the sprint planning meeting. And if circumstances change, then that accountability should mandate that an important conversation takes place to assess and either confirm or change that commitment.
"Collective ownership" is a term that is usually applied to the code base, and comes originally from XP. It means that no one person "owns" any section of the code. Anyone sufficiently skilled should be able to make changes to that code, in a responsible way. It was mutually supported by other XP practices such as continuous integration, pair programming, and so on.
But Glen's point is still valid, in that having "group accountability" is difficult to understand and implement:
There can be only ONE person accountability. Many can be responsible. Multiple accountability violates the core principle of management. That accountable person can flow down responsibilities. Those principles come from not only project management but GAAP, SOX, and business governance.
And of course the collective accountability of the code is highly domain and context sensitive as well.
This is one of the difficult parts to understand about self organizing teams in general and agile development teams in particular. In our interview with Christopher Avery at the Agile 2009 conference, this topic was discussed in detail. We asked Avery about how individual responsibility is related to self organizing teams:
I was looking for a way to teach smart people how to build teams and remember the beginning of our interview, what's the essence? The essence is the stuff called shared responsibility, when people feel the sense of shared ownership for some bigger thing, then their behavior automatically changes, organically changes. I have a set of tips for teaching people how to do that.
.... If we get focused on being in the same boat together and the larger success, then what that means is we are each willing, if we feel a sense of ownership what it means is we are going to be organically willing to fill in the gap, fill in the holes, improve the process. They say that roles on a team are emergent and the reason roles on a team are emergent is because teams are always temporary and they're defined by the larger task and when people feel a sense of getting that thing done, then they step in and do what needs to be done.
What Avery teaches is that because there is no individual failure, and no individual success, that individual accountability alone is not enough. So although there still is individual accountability, the failure of one, is the failure of the team (known as the "it's not my wing on fire" principle). And the team needs to take ownership for the success of the project regardless of who fails.
Does group accountability resonate with you? Is there an ambiguity in the ways we use "accountability", "responsibility" and "ownership"? And, most importantly, how does this affect your results?