Agile promotes less accountability, not more

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.


About postagilist

Architect, Manager, Developer, Musician, Post-Agile thought leader
This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

3 Responses to Agile promotes less accountability, not more

  1. I think there may be a misunderstanding here. When Agile talks about accountability it is generally at a story level that this association is made. Each time a developer takes accountability for a story they are taking ownership that they expect the whole team will hold against them. At standup each individual talks about their cards with respect to what they did since meeting last and what they plan on doing till the next standup. This is where their accountability is upheld.

    Even when pair programming (if done), there is always one developer that is ultimately accountable for the card.

    • PostAgilist says:

      Hi Renee

      Thanks for commenting.

      One continuing problem with debating “Agile” is everyone has a different opinion of what it is.

      There is nothing particularly required about stories in Agile; they are often found together.

      In any case, even if someone was accountable at a story level, it’s a transient accountability and a narrow one at that.

      Noone “owns” the DB layer; everyone hacks at the DB layer to do their own story.

      After the story is finished, no records are kept, so 6 months down the line, who worked on it?

      Meanwhile whatever ownership they had will be undone by the next refactoring, by whomever wants to do so.

      The DB Layer will be a mess since no one person owns it, etc.

      I’m not sure your comments negate my premise; they seem to reinforce it — “Agile” and “Accountability” are used as meaningless virtue words….they are not accountable in the way that people have traditionally used the word, but they use the word anyway…. orwell style… as a glittering generality.


  2. Bob Bryan says:

    Very good point. Collective ownership not only promotes less accountability, it also slows the project down because developers are not nearly as productive when they have to go sifting through a ton of code that someone else wrote and try to understand their thinking, which is often quite foreign to how they would do things.. Some have trouble resisting the urge to re-design the code to work “their way” regardless of how well it is written.

    Robert L. Glass wrote a book called “Facts and Fallacies of Software Engineering.” In that book, he points out that if more than 20% – 25% of the code needs to be modified, then it is more efficient to rewrite the code from scratch – which really suggests that you want to try and spend more time up front to nail the requirements as best you can, and then plan on writing the code just once with just one developer assigned per component. Of course there are always missing requirements and new features that the customer realizes he would like to have. Regardless of whether using agile or some other methodology – the project team needs to be sensitive to that and thus there will be times that the code will need to be updated. But, that does not mean to imply that the best way to run a project is to plan on updating that same code on a daily, weekly, or monthly basis. Doing that is not more effective or efficient. It is less effective and less efficient that reduces project productivity which results in fewer features implemented and/or takes more time.

    Another problem with collective code ownership is that if a bunch of developers end up working on the same code, that code becomes harder to maintain because a potpourri of ideas and techniques are used. Compare that with assigning just one developer to a component – which should make the code much more consistent and thus easier to understand and maintain.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s