In most processes, like software development, it is assumed that quality will be higher when people are given ownership to product, project, modules, task, etc. Ownership should involve responsibility, but also the right to decide. In development, ownership of a task or backlog item, should put a responsibility on the developer to create something that will meet the requirements and other criteria, but also let the developer be part of the decision for how to fulfill those in a technical manner.

Going up in the development process hierarchy, you usually have a product owner that has ownership of the business requirements, maybe reflected in epics or features, depending on the the breakdown. I will come back to this later.

The processed we commonly use in software development today can be said to originate from industrial trends that emerged in Japan after WWII. Taiichi Ohno at Toyota was one of the fathers to what is now called lean manufacturing. He used Kanban to increase the efficiency. Many developers know the Kanban board as a way of moving a task across different states. There’s also a psychology effect to this, as the tasks can be physical objects like yellow notes that are moved across a whiteboard with states as columns, and one get that happy feeling when tasks begin filling up the “done” column.

Whilst ownership of a task is given to a developer, the Kanban board can include a number for work in progress limit on columns. The idea behind this is that if tasks pile up in a column, this indicate a bottleneck. Solving this requires reassigning people to tasks in this state, often also creating a cross-functional team. Let’s say in a development process, one of the states is “testing”. A task cannot be said to be “done” or finished before passing tests, and in order to deliver features to customers, tasks must be finished. If now we say that no more than 5 tasks can be in the testing state at the same time, if we now get 6 tasks, this would require the team to be reassigned to tasks in testing state, removing the bottleneck and moving them to “done”, before going back to their previous tasks. Ownership is thus moved from individual tasks to the product or feature being delivered.

Initially, I said that product owners will have ownership of features or epics, i.e. what’s above development tasks in a breakdown process. I believe that this ownership also should include a responsibility for making sure that the customer’s business value is also met, both regarding quality and functionality. To put it simple – the product owner should be assigned a task for testing the features, based on the acceptance criteria they put down, and based on user feedback, make sure that the feature was what gave the customer value. The latter can be accomplished by telemetry and close dialog with pilot customers.

Another gain with this cross-functional reassignment is that users will learn from each other. E.g. a developer might see that testing can be improved by having automatic tests, thus making the delivery process more effective. And the team will learn more about the entire product, making the ownership even stronger.

Also, if you build software using agile methods like scrum, the development process has an iteration cycle as well. In scrum, the analysis is called the retrospective and it’s the team that decided what parts of the process they feel are good and want to improve further upon. The team will then get ownership to the process as it’s their process.

My last take on ownership is that the common way of building and deploying software these days, where the feedback loop is shortened with version control, continuous integration/delivery and telemetry/monitoring, makes it even more easy to have the ownership all the way down to the source code that is delivered. There are a number of gatekeepers, like automatic tests, that can give a developer feedback for source code for a given task they checked in to the version control system before it’s deployed to customers, and telemetry will give feedback for what happens at the customer side when they use the application.