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.When I've asked the not-making-progress question, people with agile principle experience say things such as "We didn't finish the features we thought we could in that time, so we adapted what we thought we could do in the next part of the project" or "We started implementing pieces of the architecture but realized we weren't going to meet the schedule, so we started knocking off features." If the candidate doesn't explain what he or she changed, I'll ask, "What did you do about that?" I want to see if the candidate took some initiative to change the project. The initiative will help a candidate see how to apply the agile principles on projects here.
I also like to ask about collaboration skills, because an agile team works together in much more intense ways than a plan-driven team. I'll ask questions similar to these:
- "Give me an example of a time you worked closely with one or more members of the project team. What did you do, and what happened?"
- "Did your team ever encounter a time when it needed to reorganize and change how it worked?" If the answer is yes, then ask, "What happened?"
A couple of questions may be enough for a phone screen. But before you use these questions, return to your job analysis and review the agile principles. Are there other principles you'd rather ask about in a phone screen? Maybe you want to ask about maintaining the technical excellence of the code. Maybe you need to know more about how people reflect themselves in their work. You can make behavior-description questions relevant to any of the agile principles.
Beware the Leading-Question Trap
Make sure when you're asking your phone screen questions that you don't ask leading questions, which lead the candidate to answer yes or no. Here's one: "Your project team values working software as the primary measure of project progress, right?" Instead, ask how the candidate or the team measured progress as I suggested earlier. Or ask questions such as "How often did you release something to the rest of the project team?"
Recognizing candidates who are capable of performing well on agile teams doesn't require keywords. It requires thinking about the principles and asking questions that allow the candidate to show you she understands and applies the principles in her daily work—even if the resume doesn't describe particular keywords.
