Rebecca Porterfield asks “can Agile work in a culture of single point accountability?” The question stumped a panel discussion. Too bad I wasn’t there, I’d have been able to give the usual pricey consultant answer: “It depends.”
(cue laugh track)
In all seriousness, it depends on what you mean by “work.” I personally have very high standards for “working” Agile. Agile isn’t a way of doing, it’s a way of being. So do I believe Agile can work in the spirit of its greatest potential, as a means to enable the shift from an deterministic organization to a learning organization (a la Senge), in a culture of single point accountability?
Can a possum stop a car?
Accountability When Agile is a Process
Sure, Agile can work as a process for incrementally creating quality software product when we insist on maintaining single-point accountability, exactly as Rebecca successfully implemented in her project. You can “wrap” the Delivery Team in Agile and use the Product Owner and ScrumMaster as the “interfaces” for the team. You can even promote individual accountability in such a scenario:
- Product Owner (PO) — on the hook for the health of the (software) product
- Team Coach/ScrumMaster (SM) — on the hook for the health of the Team and their adoption/adaptation of the process
- Delivery Team — on the hook for demonstrating a working product increment at the end of each iteration
“Hey Derek, not too fast! That last one is team accountability! So there isn’t individual accountability at the team level!”
Uh, no. There certainly is. In the context of the entire Agile Team (e.g. a Scrum Team consisting of a SM, PO, and Folks Who Make the Software Product Exist) the Delivery Team is accountable only so far as they collectively build working product. Individually, however:
- Delivery Team Member — on the hook to the rest of their Team for whatever commitments they make each day at standup; for asking for help when needed; and for swarming and providing help as needed.
See ? If we are talking about a culture of accountability, then accountability depends in what context you view it. Each person both has individual accountability and also is part of a Team that has team accountability. In the context of the Delivery Team, Brian the Developer is accountable for the tasks he signs up for and tells his team “by tomorrow I will complete…” In the context of accountability to the rest of the organization, however, there is no individual accountability at the Team level lest we promote siloed work and blame-shifting and all the other joys of WaterGile. But in the same context of the rest of the organization, Geri the PO is the single-point of accountability for the “health of the (software) product (that the team delivers every increment).”
But can Geri truly be single-point accountable for the R-O-I of the product? Because she is also part of the larger team of Product Management, which is team-accountable for making that R-O-I manifest and be something the organization can use. In the context of the total utility of the software product, one must also consider the teams of marketing, sales, support, training, etc. to extract and deliver full value on the potential of the software product.
So it’s both. In a single-point accountability culture, the successful Agilist who wishes to use Agile as a process for creating potentially useful software products needs to promote team accountability and individual accountability as appropriate for the context. Asking which is more important is like asking whether “3” or “blind mice” is more important.
Lowest Common Denominator
Now, this will work for churning out product at a reasonable rate, and Fred Winslow Taylor and members of his Fan Club can clap and sing that Agile will work in a culture of single-point responsibility. Assuming that your organization has little commitment to the change necessary to achieve the hyper-productivity promises of Agile, assuming you don’t mind flat or near-flat velocity gains, flat team morale, and assuming you are okay with the criminal waste of human potential of churning out product with no real Awesomeness in it — please, be my guest. Don’t look back, some other companies might be gaining on you.
But if this doesn’t seem to align with your organization’s values, if you actually want people to work better together, to develop their full potential as a team, to realize the power of their diversity and make some truly creative and useful things… you may wish to be cautious with single-point accountability and Agile.
Because you’re robbing people of responsibility.
Responsibility — being a source or cause for results — depends on having the opportunity to be the source for those results. When you make one person (e.g. the PO, or the SM) on the hook for delivery of the product, people who don’t have the ability to deliver that product, you steal that opportunity away from the Delivery Team. And that’s the greatest paradox of how I so often see Agile being implemented.
Trying to realize these kinds of gains while preserving single-point accountability for delivery will be about as successful as the possum trying to stop the car.