Posts filed under 'agile hiring'
I like to work with recruiters. I’ve used them in the past. I refer people to them. But I am missing something here.
I just got off the phone with a recruiter. He was using some kind of a phone, either VOIP or a cell phone, but it cut in and out. I had to spell someone’s name for him twice. He didn’t hear me. I finally stopped the call because I couldn’t stand it. Stupid recruiter trick #1: Use a phone that makes someone unable to actually converse with you.
The other trick happened last week. A recruiter emailed me, looking for an “agile developer.” He said “rate is based on velocity.” This is so wrong in so many dimensions, I thought I had misread the email. I asked him. Nope, that’s what he meant. His reply, “Our client is not basing the rate on experience, but on how well and efficient the candidate’s code is. Velocity = Productivity. ” Stupid recruiter trick #2: not understanding agile and pushing the hiring manager to explain what the manager is really looking for.
OMG. I thought that with the depression/recession, stupid recruiters would be unable to keep their jobs. I guess not.
Recruiters and hiring managers: personal velocity is meaningless, especially on an agile team. The team works together to deliver features. If you persist in measuring people’s productivity, they will game the system by always estimating stories as slightly larger than they are, or breaking stories down into tasks and assigning very large numbers to those tasks.
I won’t be referring people to these guys. TSTL. (In fiction, that’s a character who is Too Stupid To Live.)
Tweet This Post
March 9th, 2010
I recently spoke with a recruiter. “I don’t understand the QA market anymore. No one is hiring except for agile people. And they want people who are developers. What’s happening to QA?”
Manual testing was never quality assurance; it was testing. And, manual testing is low-value, high cost work, especially when you compare it to automated regression testing. Now, before you assume I mean there is never a time for manual testing, no, I did not say that.
There is a time and place for exploratory testing, which tends to be more manual. There is a time and place for opportunistic testing. But the kind of system-level testing that says “Does this feature meet its acceptance criteria, and does the rest of the system still work and can we know that within a two-week timebox?” is not primarily manual testing. That’s what agile projects need. (If you’re using an incremental or iterative lifecycle, you need to know this too, just not in a two-week timebox.)
That means that agile testers have different technical skills and provide different deliverables (and value to the project) than the kinds of testers this recruiter is accustomed to.
These testers have different functional skills, solution-space domain expertise, and tool capabilities than strictly manual testers. See Four Dimensions of Technical Skill for more information. In agile teams, some of the testers don’t look much different from developers, except that their code doesn’t release. Some of the testers might be better at sitting with a product owner and saying “What does done really look like for this feature?”
Whatever their skills, these testers are multi-dimensional people, capable of much more than manual testing. They are not second class citizens, but are valuable members of the product development team.
For you recruiters, think about what value the testers add to a project team. If you’re a tester, what skills do you need to acquire to provide more value to your project team? And, managers, does this make sense to you? Does knowing about the state of the product often provide you more value than having to wait days or weeks until you can manually finish a test run make more sense?
Tweet This Post
October 2nd, 2009
At Agile 2009, I had some informal discussions with hiring managers about how to hire for their agile teams. I’m considering writing an ebook. If you think that’s a good idea, please leave me a comment or send me an email. In the meantime, I was surprised by some mistakes hiring managers make. These are my top 5 questions never to ask in an interview (for an agile team or any team!):
- Tell me about yourself. This question is too vague for most candidates and wastes everyone’s time. You want to know more specifics, such as how a candidate has contributed to current and previous projects, how they’ve added value to the organization.
- Where do you want to be in 1, 2, 3, 5 years? Can anyone actually answer that question? It doesn’t provide you any information. One hiring manager told me he wanted to know how ambitious a candidate was. I asked him why he wanted to know that and he had no answer
If ambition is something you’re looking for, a better question is “Tell me about a time you wanted a promotion. What did you do?”
- Tell me about your strengths or weaknesses. This begs the candidate to turn all weaknesses into strengths and for candidates to tell you motherhood and apple pie stories about themselves. Better questions are: “Tell me about an achievement you feel proud of” and “What areas have you been working on increasing your knowledge of or increasing your skills in?”
- Tell me about your boss. The candidate’s manager may not have been the one who hired the candidate into the organization. Without context, it’s not clear what you are asking. You might want to know “Tell me how you interact with your manager”although I’m not sure why you’d want to know. I want to know more about the candidate’s role on the team and how the team works.
- Are you married/have children/belong to a church/<any other illegal question>? Don’t go there. Does it really matter if the candidate is married with two children or single with a dog? Or something else? It matters if the candidate can do the job. You can ask, “Are there circumstances that prevent you from being here 9-5, since we have our daily standups at 9am and we pair until 5pm?” or some other question like that.
Make sure you ask questions about the candidate’s ability to do the job, not anything to satisfy your curiosity about tangential facts.
Tweet This Post
September 1st, 2009
At SD West last week, one of the folks in my talks asked about how to hire a Scrum Master. First, don’t do this:
Don’t look for a CSM. A CSM means the person has taken a 2-day workshop where he or she may have practiced some pieces of Scrum. There is no guarantee that the candidate did get through an entire timebox or finish a project.
Ok, here’s what to do. Ask these kinds of questions:
- Give me a recent example of how you helped a team develop a drumbeat, a project rhythm.
- How do you know the project is on track? (Ask for examples)
- What have you done to help a project get back on track? (Ask for examples)
- How do you obtain status from people? (Ask for examples)
- Tell me about an obstacle you recently removed. … How long did it take?
- Have you ever been in a position where the product owner wanted to add a new item to the iteration backlog after you’d started the iteration? What happened?
Because a Scrum Master helps the team stick with the process and remove obstacles, you can start with questions such as these. Consider adding an audition such as facilitating a standup meeting, working with the product owner on the backlog.
Tweet This Post
March 16th, 2009
Way back in November, I taught a half-day tutorial called “Hiring for an Agile Team” at Agile Development Practices. The participants had several questions I thought you might find useful.
Several participants wanted to know how a candidate would deal with challenging others and taking “criticism” during the workday. They had these questions:
- Tell me about a time when you participated in a debate on differences of opinion
- Tell me about a time when you went along with a team decision you disagreed with
- Tell me about a time you needed info from elsewhere but were initially unable to get it
All of these questions help an interviewer see how a candidate manages the day-to-day interactions with others, including the issue of initiative and getting along with a team.
Several participants thought they needed people who were “out of the box” thinkers. (No, I don’t know what that means, those were the participants’ words.)
- Tell me about a time when you were successful at getting/having the team take a different approach?
- Tell me about a time when you challenged the team’s direction.
Some participants were more interested in how a candidate would remove impediments to the team:
- Tell me about your day to day activities as a scrum master
- Tell me about your most challenging impediment on your most recent project
When I lead this tutorial, I always hear about “negative feedback.” Esther has renamed this to correcting feedback, and I much prefer her term.
- Tell me about a time you received feedback. How did you respond to it?
This question could be about reinforcing feedback too (what other people call positive feedback).
Several people wanted to know about flexibility in terms of role:
- Tell me about a time you started in one rule and transitioned to another role?
This question partially answers some of the commenters in Why Projects Don’t Need Specialists.
None of these questions might be right for your team or candidates, but maybe they’ll suggest questions that fit for you.
Tweet This Post
January 1st, 2009
I ran a workshop recently about hiring for an agile team, and one of the people learning to interview said, “I want a candidate who can take criticism.” I replied, “Don’t you mean feedback?” He asked, “What’s the difference?”
Oh, boy. Plenty. Criticism is when you you’re looking at a piece of code and you say, “This seems brain dead.” But if you say, “I’m confused by this piece of code,” you’ve provided me some feedback. I guarantee you, you want candidates who can take feedback.
So, if you want to know if a candidate can take feedback, here are some possible interview questions:
- “Have you recently been in a position where someone reviewed your work?” (wait for a yes answer.) “What happened?”
- Offer to work with the candidate in an audition (possibly pairing) and review as you go.
- Ask for feedback on some of you work as part of an audition and see how the candidate provides feedback.
- “How do you know your work is good?” Wait and see where the question goes. You might be able to follow up with a question such as, “Is there a way you prefer feedback on your work?”
Asking candidates about their ability to take feedback is useful. Asking about criticism is not.
Tweet This Post
March 26th, 2008
I spoke with a couple of recruiters this week. They’ve been specializing in finding test people for the last 10-15 years. (I used one of them 15 years ago, the last time I was hiring testers.) They both asked a question like this, “With all this Agile stuff, where am I going to find the testers I need?”
Agile breaks the some of the barriers between developers and testers. Both developers and testers need to write code (or scripts). The developers write small internally-facing tests. The testers write small and sometimes larger externally-facing tests. The difference is that the developers write some code that ships. All the testers’ code stays on-site.
If you’re a hiring manager, make sure you train the testers who are interested in writing code and scripts. If you’re a tester, learn to write some scripts, in some programming language, not a test tool’s proprietary scripting language. If you’re a recruiter, have a talk-to-talk with your hiring managers and tell them the testers they want to hire are worth what developers are worth–because they are developers.
Tweet This Post
February 15th, 2008
Over the past few weeks, I’ve been updating my web pages, which includes (finally) updating my workshops. One of the workshop you might be interested in is Hiring for an Agile Team. Hiring for an agile team can be a bit trickier than for more traditional project teams. The issues of culture, and personal qualities, preferences, and no-technical skills are much more important than in a non-agile team. This workshop is a full day. If you took one of my 1/2 day hiring tutorials at any of the agile conferences, this workshop goes into more depth and explores the combination of questions and auditions that will help make your interviewing and selection successful.
If you want to try this workshop, I’ll be facilitating the half-day version at Agile development Practices in December.
Tweet This Post
September 4th, 2007
On my recent trip to NZ and AU (to speak about project management), I had some informal conversations with people who could not find enough people for their projects.From my non-scientific survey, it appears that we have started a technical hiring crunch (not enough candidates for positions). Consider people you might not have considered before:
- Part-time workers
- People over 40. Yes, we can still see and hear. Development is not just a young person’s job.
- People over 65. Not everyone enjoys retirement.
- People who may not have a degree, but have an avocation for software.
I’ll be thinking about this for a while, because if we really are headed for a hiring crunch, it will be global this time.
Labels: agile hiring, recruiting
Tweet This Post
April 10th, 2007
Last week, I was working with a client in the Netherlands, talking about how to hire for an agile team. We started discussing how the management team reviews resumes. One of the managers said he looked for people under 40, because otherwise the candidate was “too old.”Well, I past 40 a long time ago, so I asked him how old he thought I was. (Yes, it was unfair and a trick question, because no man ever answers either “does this make my hips look fat” or “how old am I?” honestly.) However, the question did help him rethink his assumptions.I explained that when I started working 30 years ago, we had to test as we went along–we had no testers. If we didn’t want to manually run tests, we built regression test suites. We obtained review on every work product. We made sure our work didn’t break what was already there–every day. We had to. The costs of making defects were too high to not use the preventative ideas that the agile community has adopted.When you’re hiring for an agile team, the real question is: Can the candidate work in an agile way–the way your team works? It doesn’t matter how old the candidate is. It only matters if the candidate is willing to create chunks of working product, or is willing to learn how.
Labels: age, agile hiring
Tweet This Post
March 11th, 2007
Previous Posts