Recognizing candidates who are capable of performing well on agile teams doesn't require keyword searches through a stack of resumes. It requires asking candidates questions that allow them to show you they understand the principles and can apply them in their daily work—even if their resume doesn't list particular terms. In this StickyMinds.com column, Johanna gives some excellent tips for the interviewer and the interviewee.
I recently spoke with a recruiter who told me, "I just can't seem to find agile candidates. No one has 'stand-up meetings' listed on his resume."
When you're reviewing resumes, it would be nice to find some keywords so you could see if the candidate has had agile experience—but it's unlikely. However, implementing a few new interview techniques can increase your chances of finding people who are able to adapt to the agile practices on your project.
I recommend starting with a job analysis, so you can identify the minimum necessary skills and experience. Once you know what you need in a candidate, you can develop a phone screen. Since agile practices and projects are still new and uncommon in the industry, it's useful to find people who fit with the team and have used the agile principles (see www.agilemanifesto.org/principles.html) instead of looking for specific practices.
Use a Phone Screen to Filter Candidates
I ask about some of the agile principles in a phone screen, phrased as behavior-description questions to determine how a candidate has applied the principles in his or her work. For example, let's look at some questions I've used for the principle "Working software is the primary measure of progress": I ask about the most recent project because that experience is more likely to represent future work than previous experience. If the most recent project was a disaster or if a different project caught your eye on the resume, ask about that one instead.
I've heard a lot of answers to these questions. One developer told me he made progress because the schedule indicated progress had been made. When I probed more—"Tell me about the interim deliverables"—he had no good answers. It was clear to me he was not a good candidate. Another developer said, "I like to make short tasks for myself. I write and test as I go, checking in as I finish each little piece. I build as I go, too, so it's easy for me to see progress." Based on that answer and several others in the phone screen, the second developer was worth an in-person interview.
One tester told me, "I wanted to create a system-level regression test we could run after each build. I started developing representative tests to the regression test suite, maybe a couple of tests every week. I was able to keep up with the developers, so we knew months before our release date where things were working and where we had trouble. Then I could develop more tests in the trouble spots to help the developers pinpoint the problems." That tester had promise for an agile team, yet I would need an in-person interview to know more about his qualifications.