Agile Zone is brought to you in partnership with:

By day I'm a build and release engineer in London, but by night I'm a normal person! If anyone ever asks me what I do, I usually generarlise and say "I'm in I.T." and then check to see if they've already stopped listening. When I'm not working or blogging I can be found playing rugby or cycling around the countryside on my bike, in an attempt to keep fit and fool myself into thinking I'm still young. James is a DZone MVB and is not an employee of DZone and has posted 54 posts at DZone. You can read more from them at their website. View Full User Profile

On Collective Ownership and Responsibilities

07.04.2014
| 5621 views |
  • submit to reddit

Recently I’ve been butting heads with some people on the subject of Ownership, Responsibility and Accountability.  There seems to be a very unhealthy obsession with these things sometimes, and I think this is indicative of a less-than-ideal culture. I don’t want to say that they’re “anti-agile” because that just sounds a bit weak, and because I also think they’re not just bad for agile, they’re bad for pretty much any system. I’m not sure how familiar most people are with the “RACI matrix” concept, but in my eyes it’s downright evil in the wrong hands, and I’ve been hearing “RACI Matrix” a lot recently (it’s now on my Bullshit Bingo card).

I’ll start off by clarifying what I mean. I’ve got nothing against people owning actions or being accountable for certain particular (usually small) things, but I do take offence when pretty much everything has to be given an owner, someone accountable and someone to “take responsibility”. It’s divisive and results in lots of finger pointing, in my experience.

I much prefer the concept of shared ownership, and collective accountability. As a software delivery team, we should all feel responsible for the quality of the product, as well as the performance and the feature richness. These things shouldn’t be assigned for ownership to individuals, as it’ll create an attitude of “well it’s not my problem” among the other team members.

Here’s an example: I’ve worked in a team where one person was made the “owner” of the build system. They busied themselves making sure all the builds passed and that the system was regularly ticking over. Of course, the builds often failed and nobody cared except this one person, who then had to try to get people to fix their broken builds. It almost seemed as if people didn’t care about the fact that their software wasn’t capable of being compiled, or that the tests were failing, and in truth they didn’t. They cared about writing code and checking it in, because they didn’t “own” the build system.

One message that I always try to drive home with software delivery teams is that our objective is to make software that works for our users, not just write code. I know how easy it is for developers to just focus on checking in code, or perhaps just make sure it passes the tests in the CI system, but beyond that, their focus drops off. I know because I was once one of those developers :-) These days I try to encourage everyone to care about things such as:

  • How your code builds
  • How the tests execute
  • How good the tests are
  • How good the code is
  • How easy it is to deploy
  • How easy it is to maintain
  • How easy it is to monitor

Because it takes all of these things to produce good software that users can enjoy, which means we get paid.

Here’s another example of how “ownership” has hurt a product: A large system I once worked on was deployed into production using a complicated system of bash and perl scripts, which were cobbled together by a sysadmin who did the deployments. He became the de facto “owner” of the deployment system. There were untold issues with the running of the application because of permissions, paths etc and so forth. The deployment process was creaky and relatively untested. Since the “ownership” of this system was assigned to the sysadmin, rather than devolved or collectively shared throughout the delivery team, the “deployability” was seen as a second class citizen within the delivery team, because everybody felt like it was “owned” by one person who just happened to be on the periphery of the team at best.

So here’s what I think: The ability to monitor, maintain, deploy, test, build and create software should all be treated as first class citizens and should be the collective responsibility of everyone in the team. They should all own it, and they should all be accountable.

I would extend this out further, to include supporting systems such as environments, build systems, testing frameworks and so-on. Sure, each team might have an SME or two who focuses more on one of these things than any other, but that doesn’t make that one person accountable, responsible or the owner any more than any particular developer is the “owner” of any particular class, method or function. If I write some code that depends on a method that someone else has written, and that method is failing, I don’t just down tools, shrug my shoulders and say “well I’m not accountable for that”. That would be hugely unhelpful and I’d make no friends either. In the same way, we shouldn’t treat our supporting functions and systems as someone else’s responsibility. If we need it in order to make our software work for the end user, then it’s our collective responsibility, no matter what “it” is.

Published at DZone with permission of James Betteley, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Lund Wolfe replied on Sat, 2014/07/05 - 2:28pm

What is the best way to achieve overall quality ?  Who is accountable for quality ?  The idea behind agile is to maximize the usage and cooperation of the competent and the knowledgeable team members.

Is this best done with collective accountability or organizing/breaking into silos of specialists of some form ?  Some people accept more accountability for their work and some are more competent in their role than others.  I think the ideal is collective accountability, letting the team self-organize, continuously reorganize such that no area becomes a quality weak point for very long.

On the other hand, if helplessness and failure are expected, it can be very convenient to point to individuals for blame and punishment ;-)

Regardless of the form of organization, quality itself is something to aim for rather than an expected goal.

Serguei Meerkat replied on Sat, 2014/07/05 - 4:35pm

Collective responsibility means no responsibility at all.

It means the decisions are not made by the guy who then will have to report to the people paying salaries, but by those who can bully everybody else and then pretend that it is not their, but "a teams fault" when things go wrong.

Your example of the "deployment system" that "was creaky" simply shows that the problem lies in the lack of responsibility. This is what happens when "team is responsible" instead of someone been in charge and ensuring that everything what was needed was there and done well.


Don Zampano replied on Wed, 2014/08/06 - 9:16am

The term scrum derives from team sports. And in team sports the whole team is responsible for winning or losing. Maybe one or more team members have a bad day but that only means that the others have to do more. And an attacker cannot blame a defender if he does not work in the defense too when it's needed.

So, collective responsibility is nothing theoretical - it practised hundreds of years.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.