Horizontal, “collective ownership” teams provide less accountability, not more.
In a traditional shop, someone or some group would own a given feature/domain. Say Bob owns the DB Data Access Layer and Jane owns the Webservices.
Then, months down the road, if someone has a question or problem with the DAL, they know who to talk to, and who is responsible for it: Bob.
In an “Agile”/Scrum collective ownership shop, who owns the code?
The “team”. In fact it may span several “teams”, none of who’s membership is particularly attached to the feature/domain.
So in an “Agile” shop, one might have to talk to dozens of people to find the answer, and each one of them can punt on it.
“Oh, Jill and Jack worked on that, and then a few people swarmed over it. I’m not even sure what parts of the system are using that feature right now. Maybe talk to Marty and Sarah?”
This is plausable deniability, not accountability.
Further, in most “Agile” processes, especially Scrum, the PO, BA, etc, are accountable to noone, and no metrics are kept about their performance.
No metrics about how PO changes affect the burndown are kept, no metrics about how many changes were made is kept; no metrics about how many changes were reversed and reversed yet again in subsequent sprints.
Agile is not more accountable than traditional process … it is strikingly less so.
This is one of the things that prevents agile from “scaling” … not only does it not scale when team size is increased, it doesn’t scale over time.
The farther you go in time from when a piece of code was developed, the less likely anyone will remember enough about it to actually provide any useful answers.