I spoke with a recruiter yesterday about how to hire people for an agile team. Her client had suggested she look for people with XP experience, and that candidates have “stand-up meetings” on their resume. Oh no. Looking for agile people is much more than keywords.If you’re recruiting for an agile team member, first, decide what’s most important to you. Do you care about the lifecycle or the practices? Which ones? Or, do you care more about the cultural fit of the person into the team and the ability to work with a team? There’s no right or wrong answer, but it’s worth knowing.Here are some lifecycles you may encounter:
XP (eXtreme Programming): 1- (or 2-)week iterations. See Ron Jeffries’ site.
FDD (Feature Driven Development): iterations can be as long as 6 weeks (I’ve never been a part of an FDD project, so I may be wrong on this). See Feature Driven Development.
Crystal: Alistair Cockburn has a whole variety of lifecycle adaptations based on Crystal. Although it’s implementation by feature, I don’t believe there is a particular length timebox for an iteration.
DSDM (Dynamic Systems Development Method: See DSDM Lifecycle (free registration required). DSDM does have implementation by feature, but it’s not clear to me the timeboxes are of fixed length.
I’m most familiar with and comfortable with Scrum and XP (I’m a Certifed Scrum Master). If I’ve made any mistakes in this list, please let me know.So, when reviewing a resume for an agile, look for the lifecycle names in this list. If you don’t see any, don’t give up hope. Look for an iterative lifecycle, such as RUP, UP, Evo, or an incremental lifecycle such as staged delivery or design to schedule.Reviewing resumes is important. But don’t throw people out because they don’t have exactly the keyword you’re looking for. You’ll throw out a lot of qualified people that way. See Tips for Reviewing Resumes for more info. My next blog posting will be about agile practices that you might see on a resume.
P.S. Thank you to Jason Yip who updated my iteration time for XP.
A few weeks ago at the “Hiring for an Agile Team” session, the group generated a number of behavior-description questions. I promised I would post them, so here they are:
“Tell me about a time you made a mistake.”
Using the context of shipping/releasing a product late: “What did you change?” (Notice the past tense of “did.” When interviewing for an agile team, the group expected that the candidate would take some initiative for change. And, by using the word “did,” the candidate is less likely to take this as a hypothetical question.)
“Tell me about a time you/your team changed course.”
“Tell me about a time you performed another role on a project.” (looking for people who are comfortable roaming around a team, doing what needs to be done.)
“Tell me about a time you worked with people on their projects.” (Looking for people who can coach.)
“Tell me about a time you made a difference.”
“Tell me about a time your daily priorities changed.”
There were tons of other great questions. If you participated in that session (or even if not!) and you have some questions you have found have helped you looking for people to fit into an Agile team, please leave a comment here.
Last week at the Agile conference, a participant in my “Hiring for an Agile Team” session asked how to know if the people she was interviewing–who had no experience as part of an agile team–might actually work in the team. As she said, “I can’t wait for the perfect person. I can train, but I need people who are capable of doing the work even if they haven’t done it before.”
Drum roll, please. This is exactly why auditions are a necessary part of your interviewing toolbox. I suggested that she first define the behaviors she needed to see. In this case, it’s the ability to do test-driven development. I suggested she explain test-driven development. I also suggested that during the phone screen or emails setting up the interview that she point candidates to articles she particularly likes about test-driven development. (I suggested she consider testdriven.com or Keith Ray’s blog.) Now the candidate knows to expect an audition, even if it’s something the candidate hasn’t done before.
During the interview, ask the candidate to design something–something similar to your product is best, but you can use an open source product, or even something like a factorial function. The key is to explain that you’ll check in every five minutes to see how the candidate is doing. When you check in, ask to see the tests and the code. Say, “Thank you, I’ll check back later” and walk away. As you check in, you can see if the just the code is growing, or if the tests and the code are growing together.
Not everyone can teach him or herself test-driven development. The key with this audition is to look for forward progress, not perfection. In my opinion, this audition is better than a hypothetical question.And, in case you’re wondering, no, I suggested a whole bunch of questions she could ask too, about ability to learn skills and adaptability. But I suspect that starting with this kind of an audition will help clarify whether the candidate could do the work at all. Always a useful thing to know.