Many Agilists believe that Agile is not for everyone. Some people do not fit well into the Agile philosophy and bring negative undercurrents to the functioning of the team. In an interesting thread on the Extreme Programming group, members discussed ways to evaluate if a person is a good fit for XP. The group discussed various factors on which the evaluation criteria should be focused.
Ken Boucher suggested that soft skills like, communication and ability to work with the team, are more important than the programming skills. According to him, programming skills can be taught but teaching soft skills takes longer and is difficult. Ken added that they do day long interviews which include pair programming sessions, white-board designing and having lunch together for evaluating both technical and soft skills.
On the other hand, Kevin Petteys debated that communication skills are subjective and the real evaluation of the person comes from technical skills. According to him, he had been on projects where there were well spoken people who knew nothing about programming.
David Peterson suggested that programming and communication go hand in hand. If a person cannot communicate clearly, there are less chances that he would be able to write clear code. Pat Maddox, suggested pair programming with the candidate as a way to evaluate both technical and communication skills. According to him, pairing reveals important facts like,
- Can they learn patterns quickly after I teach them? (maybe they don't know red-green-refactor. That's okay. Can they do it for the second test we write though?)
- How sharp are they algorithmically?
- Do they recognize opportunities to refactor?
- How do they communicate when thinking through a problem?
Some members on the group objected to pair programming, as an evaluation technique, citing reasons that the candidate might feel threatened or he might get the feeling that he is being subjected to a stressful situation. Other members debated that if a person feels threatened then may be he is not a good fit for XP.
The discussion then drifted towards the best way to evaluate a person technically. Most members agreed that writing code was one of the best ways. Kent Beck added, that writing code communicates a lot about the approach to work, however, it does not measure much about the character and interpersonal style. The group discussed and debated the type of coding assignment. Some members believed that canned problems like the FizzBuzz test might be handy whereas others thought that canned solutions do not reveal much about the capability of the individual to react to real world issues. They advocated real life production worthy problems. D.André Dhondt suggested a middle ground,
There are definitely pros and cons to pairing with a pre-canned sample vs real code. I wonder if I'd be happier with both. Let the person work independently for 45 minutes on a pre-canned sample, then pair with the person on a real story (but one that's carefully selected for fewer company-specific or industry-specific nuances).
D.André added that the main thing that he is looking at is communication, cadence and coach-ability. All this is easy to determine if there is enough collaboration happening, irrespective of pre-canned or real world scenario.
Craig Davidson tried to summarize the discussion with his thoughts. According to him, the most important thing to look for is enthusiasm and passion to work on an XP project. There should be a craving to learn. The person should care about the languages he knows and the problems he can solve.
In summary, most members on the group agreed that a good fit needs to have the right combination of technical and soft skills. There was a general consensus that pair programming with the potential candidate would be able to reveal these skills. Other factors that need attention are enthusiasm and eagerness to work as a part of XP team.
