For many recruiters reviewing a resume is a simple task. It's binary. The buzzword bingo they play is matched by the increasingly infuriating practice of loading CV's with massive lists of all the technologies that the candidates has ever used, looked at or heard that someone else was using in a nearby room. It's an antipattern created somewhere between naive recruiting practices and savvy developers to circumvent keyword searching and the buzzword bingo. In ThoughtWorks recruiting "Agile" experience is something I'm wary of.
The problem with this thinking is that "Agile" in this form does not exist. Recruiters looking in this way will miss out on the majority of great candidates. Agile is a conceptual framework not a language or a certificate for your wall, though I'm sure they're available. Working within the binary world of "has Agile/does not have Agile" would alienate and turn away some of the brightest and gifted developers I've seen. If a candidate has a dearth of experience in a public sector organisation it's more unlikely they will have encountered the all-singing all-dancing index card waving "Agile" we know and love - but then should we discount them? In looking at a resume or talking to a candidate I'm always looking for evidence of skills beyond that of "Tester" or "Developer".
Too often experiences of the technical practices of XP are mistaken for the behaviors we should be looking for. To people who have not been exposed to "Agile" thinking I take the time to explain what "Agile" means to ThoughtWorks. What tools and techniques they are likely to see and be a part of. I then try to ask a practical question based on their interpretation of those techniques, do they see a benefit? Do they feel there is benefit in the closer communication between the team? and between the team and the customer? I may then go on to ask what they would like to see in a development process? What would they do to improve the processes they have been involved in historically? I'm trying to ascertain how they feel about software development in general do they have that passion?
If they can demonstrate times where they are committed to delivering useful software to their customer, they are flexible enough to change software late in the process, have a will to work in a self organising team and above all want to work in close collaboration with the business and their team members - well, how much more "Agile" can you get? Ramming what is essentially a concept into a prepackaged-gift wrapped box will only rob an organisation of it's ability to recognise talent. Whether you have been a developer in a waterfall, RAD, RUP, SCRUM or some other methodology there is no reason to allow yourself to be over looked. Recruiters should be looking for potential not just clones of their current staff.
In his keynote opening QCon 2007, Kent Beck talked about the future of software development. He talked about the need to improve skills that are essential to excel in an agile development environment: Social and Technical Skills. He said social skills are more important than technical skills and suggested that Developers of the future will need to learn to listen more effectively. With the rise of a more tech-savvy business Developers will lose their "wizard" status and will need to turn to "Appreciative Attitude" and "Emotional Intelligence" as the important traits in being part of an Agile team. It's interesting to see where this goes, if Beck is proven to be right Developers used to gaining an edge by buying the book and cramming overnight will instead have to work on their interpersonal skills - look for the early adopters in the Self Help and Psychology sections of a Borders near you...