How Can I Deal With Unclaimed Tasks in My R&D Team?

Background

In traditional development mode, project managers assign tasks to individuals. In agile development, however, teams claim tasks.

During transformation, many enterprises have always found some tasks unclaimed during sprint planning.

Problem Analysis

Compared with the traditional development mode, we need to know why tasks are claimed in agile development. In Agile, neither the Agile Manifesto nor the Scrum Guide has the word "assign", but uses a term "self-organizing", as follows:

• The best architectures, requirements, and designs come from self-organizing teams (12 principles of the Agile Manifesto)
• Self-organizing teams choose how to do the work themselves, rather than being directed by someone outside the team (Scrum Guide).
• The development team is self-organized. No one (not even the Scrum master) tells the development team how to turn product backlog into increments of potentially releasable functionality (Scrum Guide).

So what is self-organizing?

Literally, "self-organizing" is the act of organizing scattered individuals or objects to create a systematic whole. The person responsible for arranging them is the organizer themselves. In agile development, a self-organizing team is a team with self-management, self-driving, and self-learning capabilities. Such a team has the following characteristics:

• Team members proactively take on tasks instead of waiting for leaders to assign tasks.
• The team is managed as a whole.
• The team still needs coaching and guidance, but not command and control.
• Team members communicate closely with one another.
• The team actively finds and addresses problems, working together to solve them.
• The team continuously improves their skills and encourages exploration and innovation.

For more details about "self-organizing", see Reference Documents.

According to the Agile Manifesto and Scrum Guide, when we practice agile development, the development team takes the initiative. The team changes from being controlled to being self-organizing, and the development task shifts from being assigned to being claimed. Claiming tasks allows people to take initiative, and autonomy motivates them to be creative and solve problems. Strong self-organizing brings high performance, great results, and a positive work environment for both teams and individuals. In addition, individuals know themselves the best and are good at assigning tasks to themselves. Compared with the conventional approach of assigning development tasks, this method is more reasonable.

Then, go back to how can l deal with unclaimed tasks in the team?

Before that, it is important to clarify one thing: during the sprint planning, it is not necessary to claim all development tasks. In the Scrum Guide, it is noted that "tasks are claimed on demand during Sprint Planning and Sprints." A task is claimed based on your goals during the daily scrum. In addition, Mike Cohn advised against claiming development tasks during the sprint planning. This can lead to a shift in focus from team collaboration to individual work, which violates the intention of agile development and hampers flexibility.

Generally, the reasons why no one claims a development task are as follows:

• Difficult development tasks: If a task is too difficult for most team members to handle, they may worry about working overtime and are unwilling to claim the task.
• Development tasks beyond scope: When the content of a development task is beyond the scope of the team members, for example, the development members do not know how to do testing, they might feel limited in their ability to claim the task.
• Afraid of criticizing and judging: The tasks can be challenging. Team members are afraid to fail the task and let the whole team down.

So how should we solve this problem?

Solution

The Scrum master is crucial in an agile scrum team. One of their responsibilities is to help the team become self-organizing, enabling them to approach sprint development tasks with a positive mindset. In addition, when no one is willing to claim a task, the Scrum master should help the team figure out the reasons and then take measures accordingly. The following provides solutions based on the three situations in the analysis.

• Difficult development tasks

  If the development task is too difficult, the Scrum master should organize a team to effectively break down the task and use the probe Spike technology to explore solutions for making the task easier. Then a team claims the task. Or encourage members with average technical skills and expertise to work together through pair programming.

  In CodeArts, you can split difficult user stories into child work items. In addition, you can set Assigned To and Notify in the basic information to keep track of pair programming partnerships.

  Figure 1 Story content introduction
  

  In addition, pay attention to and update the development task during the daily scrum, assess potential risks, and help the team resolve problems promptly. In the Sprint retrospective, analyze this type of situation, output a list of team-based standard procedures, and record the solution in the team Wiki. Huawei Cloud CodeArts provides the Wiki feature to sort out and record the working methods for the team.

• Development tasks beyond scope

  Agile promotes cross-functional teams, but cross-functional teams do not mean that one person can do everything. The cross-functional teams here usually are T-shaped talent with multiple skills (Each team member has expertise in one area and knowledge in other areas). The Scrum master should organize and manage the member technology matrix with the team. They should also identify the areas where the team lacks expertise and facilitate knowledge sharing among team members. Regular activities like technology sharing sessions can help team members learn new skills. This encourages team members to do other tasks during the sprint. Additionally, members with specific expertise and those who are interested can collaborate as a team to do tasks using pair programming. This allows for the enhancement of individual skills and technology knowledge. By developing T-shaped capabilities among team members, they can have more choices when claiming tasks, back up the team, and reduce the occurrence of unclaimed tasks. In addition, the Scrum master also needs to focus on daily risk assessment and guide the team in reviewing tasks and updating the team Wiki.

• Afraid of criticizing and judging

  The tasks can be challenging. Team members are afraid to fail the task and let the whole team down. The Scrum master should express the idea of teamwork, guide and highlight Scrum values, respect the background and experience of each team member, choose development tasks, and give credits to team members who have the courage to try. In our workplace, we can put slogans (such as "respect others" and "team over individual") on walls and whiteboards. This helps shift the team's mindset and encourages them to take on more challenging tasks over time. And the Scrum master should fully support those who are willing to challenge difficult tasks. During Sprint retrospective, make sure the focus is to discuss ways to improve works rather than criticizing and judging others.

Summary

The preceding three situations where no one claims the task are common. However, every company or team faces different circumstances in their projects. Therefore, it is impossible to list all the situations. You need to analyze your actual situation. For example, an agile team that has just transformed may prefer semi-assignment and semi-claiming for their development tasks. This is like China's economy aiming to be market-oriented with proper macro control. No matter which strategy we choose, team members should be motivated to actively claim tasks, arrange them as necessary, and promptly manage risks. If needed, we may need to seek support from other sources or leaders to ensure the iteration goal is not affected.