Once you've seen some evidence of a lifecycle, look for the practices the candidate has used on projects. To be honest, I can imagine seeing one or two of these on a resume; certainly not all.

• Test-driven development (likely to be on a resume)
• Unit testing (likely to be on a resume)
• Pair programming (likely to be on a resume)
• Continuous integration
• Rolling wave planning
• Frequent refactoring
• Frequent customer interaction
• Minimizing up-front planning and design
• Being honest about where things are
• Short iterations

I would be wary of what I do see on resumes. Here's a true story. I met a project manager recently who said he was managing an agile project. I asked what lifecycle he used. "Agile" was the answer. So I asked how long the iterations were. "Oh, as long as we need." I asked if the team was following Scrum or FDD or some specific lifecycle, and he said again, "Just Agile."

Ok. I must not be asking the question correctly. So I asked which practices the team used. "Continuous integration, standup meetings." I asked about TDD or pairing or rolling wave planning. Nope, none of those. When I asked more questions, it turned out their "standup" meeting took an hour and everyone sat down in a conference room.

His project was being disbanded because the project team didn't deliver. (What a surprise--NOT!) These people are all putting "agile" kinds of things on their resumes, and that project sure wasn't.

So even if you see the practices listed (or if you don't), make sure you ask behavior-description questions to see what the person actually did. I'll give examples of those questions in my next blog post.

posted by Johanna Rothman at at 11:34 AM | link |