Developer Ownership

For me, one of the most important aspects of the agile movement has been self-management. Moving from a “here, work on this” management model to a “let’s work as a team” has made huge strides in productivity for development groups around the world. One of the key tenants of this has been ownership.

Ownership vs Assignment

Traditionally (and in most jobs), it’s your supervisor’s or manager’s job to assign tasks to the team. They know what the workload is, what the timelines are, and what works needs to get done. Naturally, they should be the ones to tell you what to do. In this traditional environment, you come to work, talk to your manager, and do what they tell you.

This does work to a degree – we’ve been doing it for centuries, across multiple industries. In some industries, it works extremely well. In ones where the output is creative in nature, not so much.

Problems that require creativity require the worker to care about their output. Where there’s various degrees of output, from “the bare minimum to work” to “a robust, complete solution”, the quality of the work is entirely up to the person doing it. If someone doesn’t care about the problem they’re solving, where do you think they’re going to lean on the spectrum? Compare this to some other jobs, where you’ve either completed the task or you haven’t – there’s not a lot of room for personal expression or variation on quality.

Ownership

This is where ownership comes in. Ownership is the difference between “this is my task” and “I’ve been given this task”. The person doing the work has made a personal commitment to complete the task they’ve selected. Their name is all over it, they’re accountable to themselves, the team, and the company for its completion.

I think it goes without saying how powerful this concept of ownership is. No longer are you responsible to some 3rd party that you may or may not care about, you’re responsible to yourself and your immediate peers. This alone is a great motivator to increase productivity and quality of work. If you don’t perform your task, you have to tell your teammates why you weren’t able to. This is a lot harder (or more honest of a process) than answering to a boss or someone who is detatched from the process.

Agile & Ownership

So how does the agile movement enable this concept of ownership in software development? Great examples are things like Kanban, focused on team collaboration, and Scrum, focused on daily accountability. Both of these techniques allow individuals to take responsibility for their contribution to the team and own the tasks they complete at work.

Kanban is a process by which the team works together to break their work into small tasks, and then individual team members are responsible for selecting and completing tasks. This is all done in a very visible and tangible way. Your name is on your task, you’re the one who selected it, and if there’s not progress on it everyone is able to tell.

Daily Scrum meetings are short meetings which allow each team member to report on their progress. Each individual team member is responsible for reporting their task’s progress, current status, and also identifying any issues they may be running into. This way team members are held accountable on a daily basis as to the tasks they chose to work on, and have every opportunity to ask for help if there is an issue preventing them from proceeding.

Self Managed Ownership

In general, the whole concept of self-managed teams plays into the ownership concept as well. In a self-managed team, each teammate is responsible for stepping up and filling a role – not because they’re told to do so, but because it’s necessary. The difference between being told to do something and stepping up and volunteering is amazing. No longer are you putting in extra hours or trudging through old code because you have to, you’re doing it because you feel a personal responsibility to the team.

Some of these processes work much better at a smaller scale – having a Kanban board for a team of 20 developers would be a mess, and trusting a whole department to become self-managed would be disasterous. To that I say – smaller teams are more effective. It’s harder to be personally accountable to 20 people in a department than it is 5 close team members.

Comments