What's the use of the team self-organizing their work if the solution is clear?

What's the use of the team self-organizing their work if the solution is clear?

The simplest and most straightforward answer to this question is: If the solution is already clear, there is no need for you as a Product Owner to prescribe this solution - the team will get there on its own and you can use this little extra time for something more valuable.

However, the reality is usually a bit more complex: If, in the mind of a Product Owner, it’s already clear who does the work, it’s tempting to cut everybody else out of the picture and collaborate on the issue only with that developer, including all the pre-work that usually leads to planning the item.

One unstated facet of this question is whether or not you are wasting everybody’s time if you leave the topic of who will actually do the work open - it might even feel unnatural to pretend as if no one knew that it will be that one person doing the work, after all.

The Notion Of Assigning Work Is Already Wrong

Discussions like these usually revolve around the question when the assignment for work will be done - in case of Scrum, before, during or after the planning? However, this question is already wrong. It usually comes from the limitations of JIRA as a tool, which allows for (and, depending on the configuration, requires) at most one person assigned to a ticket.

This single feature of JIRA and related tools leads many people to think that you need to assign someone at some point some work in order to get it done, and conversely, if a person does something, then it belongs to a ticket assigned to them.

Working with a team is different from working with individuals

The reality in many teams is different: A team, by definition, tackles their problems together. Like a soccer team, they can pass the ball back and forth between individuals within the team, amplifying each other’s strengths and compensating the weaknesses.

Here are some examples that happen every day in teams across the globe, even if there would be only one expert on that matter on the team:

  • Pair Programming for knowledge transfer
  • Splitting the work in tasks which can be distributed among multiple people
  • Dividing the work so that the expert can focus on the hard stuff
  • Testing stuff that has already been done while other parts are still under active development

Assigning work has numerous negative side effects

Assigning work unilaterally - meaning that you as the PO do it, and it’s not up to the team, is bad. And not only if you do the actual assignment on your backlog - if you are mentally “assigning” people to the work you have in your backlog, you commit the same mistake.

With that pre-assignment, you create a couple of self-fulfilling vicious cycles. You either consciously or unconsciously tailor the pre-work in a way that fits your desired target person, which will result in no one else being able to understand the work that needs to be done.

Your expert becomes more and more proficient in what they do, and no one will ever catch up with them - how could they, as you are effectively taking away their own freedom to chose to build up knowledge in that area?

Take a step back

If you are in a situation where this problem applies to you - meaning that you frequently assign work to specific persons before development starts - then I strongly recommend taking a step back and looking at the overall situation. It’s not only the fact that you are assigning the work that is the problem - it’s also that the team lets you get away with it and doesn’t call you out on this. When thinking about assigning work, you are no longer feeding the team a backlog of items that you want to see turned into software - you are essentially controlling and managing them, contributing to an environment where self organization, and all the benefits that come with it, will not flourish.

This post is part of the Product Owner Q&A series.