TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
There are three general strategies for deciding who works on which tasks: assign them to the most-qualified person, assign them irrespective of skill, or assign them to the least-qualified person. We tried all three approaches.
Interestingly, these data showed an overall increase in velocity when tasks were consistently assigned to the least qualified person. The difference was especially marked over long periods. Choosing the least-qualified strategy really pays off after the team has used it for several iterations, but outperforms the others even in the first iteration. The data on red card rate corresponded with those on velocity: the least-qualified teams produced the code that had the fewest surprises.
We didn’t run these experiments while we were hiring. Therefore, we don’t have data correlating task selection approach and ramp-up time. However, we assume that the least-qualified selection strategy also helps with new-hire ramp-up time as it leads to the fastest propagation of skills.
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.