Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!! It is better to wait for someone to step up than to “take over” and start assigning tasks.
Assigning tasks can be overt or subtle. Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”
In the Scrum Guide, a partial definition of self-organizing is given:
Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
A more formal definition of the concept of “self-organizing” can be found here:
Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.
The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.
What If One Person Isn’t Working?
People who are managers are often worried about this. What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing? Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.
Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.
Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs. Assigning tasks doesn’t make a person more productive.
What If There is One Task No One Wants to Do?
Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!
There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.
And, of course, there’s always the Sprint Retrospective!
Why Self-Organize – Why Is Assigning Tasks Bad?
Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.
Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees). Even if this is true, it is still easy for a person to take offence. However, most of the time it is not true. People know themselves best. People are best at assigning tasks to themselves. And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.
The ScrumMaster and Assigning Tasks
The ScrumMaster plays an important role in Scrum. Part of this role is to encourage self-organization on a team. The ScrumMaster should never be assigning tasks to team members under any circumstances. And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks. If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening. The ScrumMaster needs to be constantly aware of the activity on his or her team.
I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:
This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.
Affiliated Promotions:
Please share!
