Tuesday, December 2, 2008

Self-Selecting Specialists

One of the principles of many agile (and agile-like) methodologies is the idea of generalist resources. This is a project manager's dream - anyone on the team can do any of the team's work! I've never seen this actually happen.

In practice, the people I work with are what I call self-selecting specialists. Since we are committing to work as a team, then the team gets to decide among itself who actually does what part of the work. And when you give the people on a team the ability to choose what they do, I've always seen it result in specialization.

Take some of the typical mix of tasks in my current QA team:
  • fix a bug in our automated test report
  • an enhancement to the log fetcher that grabs logs from a set of machines you specify
  • create a code interface to manipulate some third-party software (and we'll later write regression tests that use this)
  • poke at the failover feature in conjunction with writes over a certain protocol
  • run some tests comparing the performance of various writing programs on Windows (copy, drag-and-drop, Robocopy, etc)
If the team gets to pick, you can pretty much guess who's going to pick what. The guy who considers himself a software engineer (just moonlighting in QA) will want the enhancement to the log fetcher. The guy who likes designing test system and wants to learn object-oriented perl will volunteer to create the interface to the third-party software. My more junior guy will want the performance comparisons (since they're structured and he knows he knows how to do that). Etc....

Yup, in theory we should all be generalists. But we're all human: we do what we enjoy doing, we do what we think we're going to be successful at, we do what feels like just a little bit of a stretch. We end up specializing not because someone told us to, but because we chose to do it.

And - other than our beleagured project manager and our process zealots - I think that's okay. To me, this is a prime opportunity to show off the powers of pairing. Let the specialist do the work that he enjoys, and pair someone else with him so that the other person has exposure. You still get the speed and reliability benefits of specialization, and you also get the increased coverage and learning that generalists incur.

So here are the two heuristics we try to use for specialists:
  1. You wanna do something you "specialize" in? Great. Do it.
  2. You have to pair with someone who does things you're weaker in, and you have to drive the pair. I don't care when or what, but you have to do it for at least 8 hours a week. That way you get the fun stuff that you like and are good at, plus you're also learning.
At least for the teams I've worked on, self-specialization is a choice that pretty much every member of the team has made. I'm not going to fight it. Instead, I choose to use that self-selection as a solid base, and nudge each team member to make that base bigger, working always from the person's comfort zone.... and using pairing to just expand that comfort zone a little at a time.

No comments:

Post a Comment