How Agile Teams Make Self-Assignment Work

I complained a few days ago about abstracts that are written as teasers rather than summarizing the paper's results. The abstract for Masood2020a feels like one of those, but once you get into the paper itself you realize that a short summary isn't really possible. Figure 5 (included at the bottom of this post—click for the full-size image) shows just how complicated the forces and feedback loops are, and that complexity is why researchers need to use both qualitative and quantitative methods. As a reformed engineer my instinct is always to reach for the latter, but working with some world-class qualitative researchers taught me that close inspection of a few cases can be as rigorous as statistics and can produce insights that number crunching cannot.

The takeaway from this paper for me is the recommendations at the end, some of this are listed below. As is often the case, these are not surprising, but in many cases the opposite conclusion would have been just as plausible; what research like this does is tell us which believable alternative is true.

• Managers can ensure that the self-assignment decisions do not lead to increased specializations or threaten cross-functionality, rather assignment choices provide equal opportunities to learn (technology, applications, and tools) to maintain a balance of knowledge sharing (S4).
• Managers can guide the team members if they feel they have committed to something which is hard to accomplish. However, they should avoid discouraging members to pick complex tasks. Taking away tasks from the team members is also not recommended (S4).
• Once required information has been conveyed among the team and estimates and task breakdown is done, the manager can step out from the assignment sessions (S3).
• If an urgent task comes in during a running sprint, the manager can ask for volunteers rather than imposing tasks on someone. Knowing the time pressure, it is likely that person with relevant skills will pick such a task (S2).
• If multiple people are interested in working on the same task, they can either pair up (S12) or the manager can step in and let one of them pick a task (S4), ensuring that the next time the other one gets to select their preferred task (S13).
• Managers can initially let the new team members observe the team allocating their tasks and understand the task allocation strategies. Other team members can help them choose easier tasks (S4) or pair them up with senior members for better understanding of the process (S12).
• The team members miss updating their tasks on their preferred project management platform, which can potentially lead to issues, e.g., multiple people working on similar tasks. Automatic reminders through tools or reminders in daily stand-ups can be useful to remind them to update their tasks regularly (S6).
• Individuals can pick tasks in the presence of other team members, e.g., at planning or at stand-up. This way other team members who have more knowledge about the task can provide assistance and transfer relevant knowledge if needed (S13).
• The manager or team could include some 'stretch tasks' in every sprint, i.e., a few extra tasks ready, elaborated and estimated, in reserve, so team members can self-assign and complete them if they happen to finish all the other tasks early (S5).
• Teams starting with self-assignment can initially apply for a part of their project, e.g., new development features, enhancements etc., rather practicing for the entire project (S4).

The richness of this paper's results presents me with a problem. As I have repeatedly written elsewhere, I think we should supplement or replace the "build a big piece of software in a team" course in most undergraduate computer science programs with an introduction to the methods and findings of empirical software engineering. I know how to teach the quantitative side: introduce Pandas, have students analyze a few small datasets so that they get a feel for basic statistics, and then have them recapitulate some of the findings from this site.

But how can we teach qualitative methods to this audience? I think we should—I don't want to perpetuate today's biases and blindspots—but what exercises could we give students? Many researchers now make their quantitative data available online, but I don't know of any archive of interviews and videos, and suspect that it would be difficult to create one without violating ethical and privacy rules. Having students analyze questions and responses from discussion forums is the best thing I've been able to come up with; if someone has a better idea, I'd be grateful if you could reach out.