Another question they had was:
- Who should do which tasks?
The normal approach is to put the most qualified implementor on a task. Naturally, that should ensure the task got done faster and better, right? Well, just to see how it worked, they once tried the exact opposite: putting the least qualified implementor on a task. Again, what they found was astonishing.
By always having people work on tasks that required skills they didn’t have, having people embrace their “beginner-ness”, a few things happened:
- The developers felt uncomfortable. It hurt. It felt like drinking from a fire-hose.
- After one week beginners were as productive as the experts, and even more effective the next week.
- Developers picked up skills at an amazing speed. The skill gaps in the team disappeared after just a few weeks.
- New people were brought up to speed in record time, about 2.5 to 3 weeks.
- People’s skills all rose to max after 6 weeks.
- It expanded people’s knowledge, combating the not invented here syndrome.
- It had a huge effect on the outcome.
They started looking for an explanation, and found something that seemed to fit very well with what the Zen literature calls a beginner’s mind:
- You feel out of your depth. Panic attacks may occur. You think you should know this, but you don’t.
- You’re trying hard to figure things out.
- You start noticing everything.
- You’re highly receptive to innovation. In the beginner’s mind there are many possibilities, in the expert’s mind there are few.
- You get into rapid experimental mode, just trying things out to see what happens as you don’t know where the boundaries are.
- You’re highly receptive to learning. You learn very very quickly.
Children all have a beginner’s mind, adults rarely do… except if forced by a process such as that above. The least qualified implementor would be the one that would stay in a beginner’s mind the longest.
After 2-3 weeks, when there aren’t much of a skill gap in the team, the least qualified implementer would in the duration of a 3 hour pairing session become the most qualified implementor. That’s the goal.
Although this hurts, the end result is great in terms of growth and productivity, and most people will feel much happier. This is pretty consistent with my experience. During software interviews we always ask “when were you most happy?”. We’re looking for passion, the ability to get in “the zone”, to completely focus on tasks at hand. People that can do that have the ability to have a beginner’s mind. And, almost everyone answers that they were most happy when they started at some company, or were faced with a big new task, i.e., when they were really challenged, when they were learning.
He gave a couple of examples, like a DBA that didn’t pair program while the other 5 developers would. After only a few weeks the DBA guy’s database skills were superseded by the team. Another example included a program manager that became a developer in just a few weeks.
Arlo is also careful to caution that what works for one team might not work for others. Promiscuous pairing like described above depends on a level of intensity and a level of teamwork, that you only see once a team has developed to a reasonable degree; that is, it should be out of the forming and storming phases, and in the norming or performing phase. Otherwise you need to play a little softer.
He also has a caution on team size. This has been done successfully for team of a least 4 people, but it’s better for 5, and shines with 6 team members.