Team Discussion

Pitfall of Scrum: Assigning Tasks

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:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

7 thoughts on “Pitfall of Scrum: Assigning Tasks”

  1. Volunteering for tasks makes sense.
    What about tracking who does what?
    Does that go against collective ownership of tasks/stories?

    1. Collective ownership is not officially part of Scrum, but is usually a pretty good idea. I prefer to avoid tracking who does what task. However, in some circumstances it can be useful to start a team with individual ownership of tasks… which is allowed by Scrum.

    2. Various tools keep track of participation. Source control shows who is committing code, Jira shows who is assigned to subtasks. Fisheye helps show activity.

  2. Hi ,
    Thanks a lot for the article. You have explained in a very simple way that the Scrum Team is self-organizing and also explained how to handle the situation when someone is not upto the speed.

    I do have a follow-up question on another human aspect. Following is a scenario based on which I have my question

    SCENARIO :
    1. Let us say that we have a team of 6 people. Out of them 2 folks are experienced , highly skilled and love to work long hours. But they are introverts and just work in a silo.

    2. Other 4 team members are new to the technology and are trying to learn their way. They are somewhat reluctant to learn and take up tasks, because they are afraid of screwing them up.

    3. The two experienced team members are aggressive and they go ahead and take up 90% of the tasks during the sprint planning.

    4. The Sprint is a success because the 2 experienced folks are able to complete the tasks easily. Thus the Product owner is happy.

    In the above scenario , the end result is positive as the product owner got what he wanted. But as a whole the organization is not growing. Because the new comers are not getting opportunity to learn the intricacies of the technology , as there is no individual empowered to ask the experienced resources to train them, because it does not add any specific value to the User Story.

    QUESTION : As an organization, how can we continue the Agile journey and also at the same time accomplish the goal of continuous On-the-job training, that in short term might not add value to a particular User Story, but in long term would help the organization build the Skill level.

    1. In Scrum, the primary means of helping with this sort of problem is for the ScrumMaster to expose it clearly to all stakeholders including the team itself. Then, the ScrumMaster should be using effective retrospective techniques to get the team to try solving the problem on their own. The book “Agile Retrospectives” by Esther Derby is a great place to start, and for even more techniques the “Retr-o-mat” (http://plans-for-retrospectives.com) is a good place to go. Finally, technical training such as the Certified Scrum Developer (http://www.worldmindware.com/CertifiedScrumDeveloper) can be a great way of helping your whole team learn important technical practices as well as develop natural cross-training skills.

    2. Pair programming would help alot in this situation. Pair an experienced developer up with the less experienced programmer. Have a subtask in the story that shows the role of mentor, as well as subtasks for the work. Account for more hours spent on this task (experienced developer could do it faster by themselves), but elaborate to everyone the benefits (knowledge transfer).

Leave a Reply

Your email address will not be published. Required fields are marked *