The idea of ownership may be tricky and gets easily misunderstood or excessively exaggerated (some would say - demonized), especially by Agile dogmatists and people with limited imagination: I never said those two groups are the same though :)

That's why I'd like to be perfectly clear about what do I actually mean as an ownership and what kind of obligations should be related to being an owner (don't worry, there won't be any RACI-level classifications), but before I do that, ...

... some bold statements:

  1. Things don't just happen because:
  • ... someone has listed them down in a document / e-mail
  • ... someone has mentioned them in open discussion
  • ... someone considers them a common knowledge (hey, everyone knows that!)

  1. The shared, common understanding of a problem / topic doesn't come for free. It requires effort and time to achieve that.

  2. One case / incident / feature may have completely different priorities when considered from perspectives of various groups of people

  3. Things tend to get worse as the timespan widens - if something requires constant attention or even just periodic checks and adjustments, there should be no understatements

  4. Collective ownership sounds cool, but it will work only if all members of the collective:

  • ... understand and agree to the ground rules about what does this ownership really mean
  • ... are able to efficiently distribute the actual work within the collective and track it well enough to make sure that everything is covered
  • ... can make their work look transparent enough to the outer world so external stakeholders (I hate this word ...) know who to speak to, etc.
  • ... communicate elaborately enough to keep the coherent and widely accepted identity and future vision of the owned area - so the co-owners answer the questions about owned area in a coherent way

Point one: the 'what'

What should have an owner assigned? Project? Issue? Risk? Feature area? Module? Application? System? Class? Form? Document?

The answer is simple:
Anything that is really important. Seriously, anything that's important enough to be tracked / covered. Just make sure people recognize the borders (what's in, what's not).

Point two: the 'who'

Who can be an owner? Whoever, who:

  1. Is truly interested (for whatever reasons) in owning the area for its good.
  2. Has capabilities (knowledge, resources, etc.) to be the owner.
  3. Her/his position within the organization won't prevent her/him. Basically it's about being able to make decisions on your own.

So much and so little in the same time.

Point three: the 'what-the-hell-does-it-really-mean'

But what does it really mean to be an owner?
There's no one simple answer to this question, sadly - it really depends on the owned area:

  • sometimes it means to fully and independently maintain an owned area, without an extensive external support (if it happens, it's an exception, not a rule)
  • and sometimes it's only about answering basic polls or executing other, simple activities

The key point is to explicitly state what is the area of responsibility for each particular area of ownership. It doesn't have to be a full book about resonsibility, just a short list of most important rules and expected outcomes - to make sure that everyone's on the same page.

Why so serious?

The more complex project gets, the more people are involved, the more integration is going on, the less clear some things will get:

  1. If some kind of work area is 'owned' by too many people / teams, their visions, plans, ideas may differ - that may cause technical debt to raise faster than you can imagine.
  2. If ownership is not clear enough, some area may be left without actual owner (without anyone noticing it) - as a result, the overall solution may not work or be incomplete / incorrect.
  3. If there's an owner, but his obligations are not clear, it may result in insufficient actions / communication - refer to the point above.
  4. If ownership is left unassigned on purpose (as a result of wrong understanding of collective ownership), people / teams may actually struggle for the actual ownership - that pretty much means the waste of energy and a source of potential conflicts.
  5. If the ownership is forced over someone who is not interested in the owned area, the area will suffer sooner or later.

The surprising truth

Wherever I go (or at least - wherever I went in the past until now), people do avoid explicit ownership. Barely anyone considers it a safe-guard (when the ownership's clear - everyone knows what (s)he's supposted to do and no-one will pester me for stuff I never heard of), but almost everyone finds it a burden.

Don't let that stop you though. The professional work is not like bazaar - you don't just come and pick whatever and whenever you want, not caring at all about the rest around.

Even in agile environment, there's still a clear ownership - it's just being worked out by team itself, not forced by any kind of management. Lack of reasonable ownership is the very first step towards chaos and chaos is the best way to cease the productivity and rip the quality off.

Share this post