Chris Johnston

One thing I have been thinking about lately is who owns, or should know about, tech tasks. The team I am on right now, we need to justify every tech task we do with business and if business value for that task cannot be found then it doesn’t get done.

For some reason, I really don’t like this approach and for the first time, I have read a blog that expresses what I have not been able to as of yet. John Pither calls this tech leakage and explains it as such:

If we can see the dev team as an animal in the jungle (and so forth we have other ‘animals’ such as QA teams, BA teams, Project Managers etc), then ‘dev team leakage’ refers to the cutting open of such a large and volatile jungle beast and of letting it’s gooey entrails slide out and slither amongst the wider natural setting of which the poor animal finds itself.

Yep. Basically it’s about breaking encapsulation. In the case of a dev team, there are many inner workings that need not be externalised to the outside world.

As graphic as this analogy is, I really like it (okay, I have a morbid sense of humour). Tech tasks should belong to the dev team and simply be a part of how we do our day to day jobs. I find that I spend far too much time explaining why I am doing a particular refactoring to a BA or business because the team does not own these tasks. In addition, far too many tasks never get done because we cannot justify them with business value.

One consequence of this anti-pattern is that nothing really comes out of retrospectives. Yes, do them every week, however, every action we create must first be justified with business and given some business value before we are able to carry it out. This means that we never have the chance to clean house and carry out those dev tasks that we should be doing as a part of our jobs.