TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Giving tasks to the least qualified person plays strongly into Beginner’s Mind. However, the selection needs to be wary of the distinction between competencies and skills. The optimal worker for a task is the one that is the least skillful in that task, but who has any necessary competencies. A worker who lacks a required competency will not perform the task well, regardless of skill level — and will not enter Beginner’s Mind.
Selecting implementers who are least-qualified decreases the ability of a team to develop domain experts. This is actually a good thing. Instead of domain experts, the team tends to develop task naturals.
The difference between a domain expert and a task natural is exactly the difference between a skill and a competency. A domain expert is the person on a team who is best at a skill. A task natural is someone whose competencies and interests align with a particular type of work — such as data modeling, bug hunting, or testing.
Skills and experience within a particular domain are easy to measure. Because of this, they tend to become the primary metrics that people use to determine who is “most qualified” to do a task at hand. By selecting against skills, we distributed experience around the team. Soon, everyone had the skills to work in any problem domain involved in our project.
However, once skills are roughly equivalent, it quickly becomes visible who has what competencies. Talents tend to crosscut domains — when working on a typical system you might want a natural domain modeler, a tester, and a task simplifier, for example.
The need for different talents becomes especially visible on bugs. These often require a large number of talents applied in a particular order. Each talent helps get around one problem, but a different talent is needed for the next problem. Even if there is another problem in the future that will need the same talent as the one just solved, the team can’t work on it. The next problem can’t be seen until the current problem is resolved.
Our most heinous bug required many talents to fix. It resulted from the compiler implicitly choosing two different calling conventions on the two sides of a DLL boundary. As a result, both the function and the code calling it tried to pop the function arguments off the stack. The system would repeatably crash in some totally unrelated code.
The system called the death function, which returned. The system appeared fine, but the stack and frame pointers were computed. The calling method then called something else with its bad frame pointer. This propagated through the call stack until something eventually dereferenced a pointer held on the stack. That variable’s offset was actually located in compiler-generated frame storage for a register whose value was NULL, resulting in a crash.
To solve this bug, we needed our best data analyst. We needed our compiler guru. We needed our expert tester. And we needed our most creative guy — he was the only one who could come up with more things to try. So we swapped frequently, rotating as soon as the task changed.
In 18 months of C++ development, this bug was our hardest challenge. It represented the longest time that we failed to make forward progress.
We put one pair on it. It took us 6 hours.
Agile . since Jun 23 . Index . DOCs TOP TOC
Who is responsible for completing which tasks? Different XP teams have different answers. Again, we tried several approaches and used metrics to discover which worked best for our team.
We attempted individually owned tasks and team owned tasks. For each grouping, we attempted push-based and pull-based assignment. For individually owned tasks, we tried both just-in-time and per-iteration assignment periods. This results in a total of 6 combinations.
An individually owned task is one that a single individual is responsible for completing. He will pair with others to work on it, but he will never rotate off it and is personally accountable for its completion. In contrast, team-owned tasks are the responsibility of the team as a whole. Anyone can work on them at any time.
In push-based assignment one person delegates tasks to others. This may be a manager, a Senior Engineer, an architect, or some similar person. In pull-based assignment, people grab tasks that they want to work on off of a shared space, such as a cork board. They tell the team why they should do the task, and then take it.
The data below clearly indicate that more flexible work assignments got more work done. The most efficient method was team owned tasks with pull-based assignment. Again, this gave marked improvements in both our velocity and our error rate. The difference was especially marked among the larger tasks — tasks that took over ½ a pair-day were completed much more quickly and predictably when they were team owned.
Figure 1. Task ownership and velocity
The letter codes for the categories are (T)eam owned vs (I)ndividually owned, then (A)ssigned vs (C)hosen, and finally (W)eekly vs (F)lexible duration of accountability. For each category, a mean velocity was measured across a couple of iterations. Velocity has been normalized to a percentage of the highest mean and the columns arranged in ascending order.
The worst two columns are those with weekly task assignments. All team-based assignment methods beat all individual accountability approaches. The error in these numbers is about 10%, which means that the 70% difference between the worst and the best methods is quite meaningful. The 5% to 10% difference between pull assignment and team leads is not.