You’re interested in hiring for an existing team that purports to be “agile,” whatever that means. Tell me, if you can:
- What’s core to the culture of that team — what do they hold near and dear about how they work?
- Which one technical element is a must-have — if there are any?
If you can’t answer these questions succinctly, you’re jumping the gun with your hiring.
Here are six major points to consider — three job requirements essentials, and three important aspects about hiring — before you draft a job requisition for an agile team.
Get TestRail FREE for 30 days!
Agile Essentials
I believe the success of agile is predicated on two things: creating a highly collaborative, cohesive team, and fostering the willingness to keep learning and adapting.
When I say highly collaborative, I mean team members must work with one another throughout the day, and they must work on as few things as possible. If your team members spend most of their day in their own cube, or if you have as many current work items as team members, your team is not working in a highly collaborative fashion.
If collaboration and adaptation are paramount, what should you put into your job requisition (“req”)? Keep it simple: Describe briefly how you currently work and your interest in making people comfortable with continual learning.
“We mob occasionally, and when we don’t, we prefer to pair. We seek folks comfortable working in this fashion and with regularly evolving team practices and dynamics.”
Technical Essentials
Delivering software, agile or otherwise, still demands expertise in the core technologies we employ, but we don’t need everyone to be an expert on every technology. In fact, we can do just fine with a few experienced folks in the core technologies as long as we are truly collaborating. Techniques like mobbing and pairing can do wonders to help savvy people rapidly ramp up.
Lest you think I’m discounting expertise, I firmly believe it’s essential for at least a couple of people to know each technology very well. You might survive without that expertise, but you will also waste a lot of time as a result. (Hint: You can rent expertise. Just make sure the person you rent it from excels at helping others ramp up on the technology.)
The worst thing you can put into a job req is a laundry list of technologies. All it accomplishes is chasing off candidates who might adapt well to your world.
At one place I worked, we sought an experienced C++ developer to help with test-driven development mentoring and coaching. Before I got my hands on the job req, it was an HR-produced morass of a dozen or more technical demands. I simplified the demands to the following:
“Our developers predominantly work in C++, so we seek people with solid C++ experience—and people who still want to work in this challenging language. You must also have experience helping others learn TDD.”
People Essentials
One more characteristic I consider important to software development in general (agile or not) is good problem-solving skills. While we can all learn these skills, some folks don’t appear to have much aptitude for it. I’ve seen employment end in tears when we realized that recent hires weren’t able to contribute sufficiently to development efforts, no matter how much we tried to help them along.
While you don’t need to ask your candidates to solve complex puzzles, they can be expected to think and work through mildly interesting problems and mundane, typical challenges. Doing so is pretty much our minute-to-minute job. You can explain this expectation in the job req if you like, but you could also wait to reveal it during an initial conversation.
Ultimately, however, what’s most important from an individual stance is that they want to work the way your team works.
“In addition to regular pairing, we expect programmers to produce developer-focused tests and to contribute to BDD efforts.”
Selling
While you may view hiring as having candidates sell themselves and their skills, the first mentality should be that you are selling them on your culture — you are trying to find people experienced with, and happy about, working the way you do. As such, the first focus of your req should be on making the job sound appealing. Don’t overdo it, but remember that every hire is a give-and-take negotiation process, and thus so should be the job req itself.
I mentioned earlier rewriting the job req for a TDD coach. Before doing so, an external agency sent me a couple of dozen resumes, most with neither C++ nor TDD emphasized or even mentioned. Out of the candidates, only two were anywhere near what we needed, and neither of those survived an interview.
After simplifying the job req to the essentials, we received resumes for five candidates. Four of those five looked good enough to interview, and all did well in the interviews. We ended up hiring a top-notch candidate.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Interviewing
To give candidates the best opportunities to shine, you can play out the interview across a number of forums. I’ve done this a few different ways, but here’s a three-step approach that worked well:
- Initial phone conversation: A 15-minute chat to describe the company and what we were doing, and to get a feel for what the candidate is interested in (and capable of) doing. Where I worked, this conversation was run by business folk.
- Initial technical conversation: A 15- to 30-minute chat with development team members to clarify the technical landscape and get answers to a question or two about the candidate’s background. More importantly, this call sets the stage for the core of the technical interview.
We asked developers to build code for a handful of increasingly interesting, related features. Developers were told to get back to us when done to schedule a follow-up. We expected them to spend perhaps an hour or two on their homework. We would explain that they would be expected to pair with us when ready, to add one more interesting feature.
If it took a few days for them to get back to us, that was fine; if it took a couple weeks, that was fine too. Rushing to hire a candidate is never a good idea.
Importantly, we explained that they were free to use whatever technologies they felt most comfortable with: operating system, programming language, editor and so on. The goal was on the problem-solving, not learning a new technology. We wanted them to be able to approach the forthcoming demonstration session with as much comfort as possible. (It turned out that choosing one of our desired technologies, something they weren’t so comfortable in, was always a mistake for the candidate. We reminded them of this reality.)
- Demonstration session: A 60- to 90-minute session with at least a couple of us. The candidate was asked to step us through their solution and explain choices they made. Sometimes we’d ask what they thought about alternative approaches; I remember dismissing a candidate almost immediately when they took offense at the thought that there might be a better way.
We then presented the candidate with a new feature, something that would add an interesting wrinkle to their existing solution. They were expected both to talk and work through coding a solution at the same time. Our goal wasn’t to put them on the spot; in fact, we sought to help them as they worked.
The candidates we dismissed were people who weren’t capable of interacting with us effectively. Some wanted to turn their back and scribble things for a while; while that’s perfectly acceptable, the candidates we appreciated more were the ones who could talk us through their thought processes. We most rapidly dismissed the candidates who weren’t open to listening to our suggestions.
Apart from information about their ability to solve problems, the most important part of this interaction was discerning whether we thought we wanted to work with them every day as part of our team.
We made it clear that either the candidate or we could choose to terminate the process at any step.
Sometimes we ended up on the fence. For a while, we had a second pair of developers run another interactive session, but this second session always resulted in the same uncertainty. We decided to end the interview process, one way or another, after a single session, and I believe that was the best choice. Either we knew they were a good hire, or we passed on them.
All of the above steps can be accomplished online, though of course, face to face is usually far more revealing. If at all possible, get the candidate to visit in person.
Diversity and Culture
A successful organization embraces diversity of thought and approach. While I firmly believe this diversity is important, I also believe that building a culture is an important aspect to building a successful team — which also implies that I believe teams within the same organization can and should have differing cultures.
The culture represents the shared beliefs, attitudes and preferred ways of working for a team. A healthy team understands its culture and accepts that its culture will change as it matures. It also accepts that “immature” new ideas might benefit the team, and that experimentation might be worthwhile.
While keeping open to new ways of thinking, a team should not feel like it needs to hire people who will directly subvert their current ways of working: “Oh, you do pairing? I hate pairing, and here’s why it’s stupid …” No, thanks. We don’t need the drama.
Diversity is great as long as it doesn’t threaten to destroy the team coherence. A team’s set of core values should be small and strongly held, and it should be open to practices that improve the team without jeopardizing its values.
The core Agile Manifesto values promote individuals, interactions, collaboration and responding to change. Your approach to hiring should be no different.
Article written by Jeff Langr. Jeff has spent more than half a 35-year career successfully building and delivering software using agile methods and techniques. He’s also helped countless other development teams do the same by coaching and training through his company, Langr Software Solutions, Inc.
In addition to being a contributor to Uncle Bob’s book Clean Code, Jeff is the author of five books on software development:
- Modern C++ Programming With Test-Driven Development
- Pragmatic Unit Testing
- Agile in a Flash (with Tim Ottinger)
- Agile Java
- Essential Java Style
- He is also on the technical advisory board for the Pragmatic Bookshelf.
Jeff resides in Colorado Springs, Colorado, US.
Test Automation – Anywhere, Anytime
