The Ownership for projects / products / services - I vote 'for'

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...

5 years ago

Latest Post Mixing warsaw.ex by Sebastian Gebski

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:
  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:

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:

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.

Sebastian Gebski

Published 5 years ago

Comments?

Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.