In my previous posts (Part 1 and Part 2) we explored some of the technical differences between Developers, Testers, and Business Analysts when they move from more traditional to agile teams. Here I’ll continue the discussion focusing on more of the soft skills that are relevant, not required, when you move to agile self-directed development teams.

Believe it or not, I think the soft skills are more important than the technical ones when trying to form high-performance agile teams. Lets dig in and see how we can assess them…

A Focus on Soft Skill & Behavioral Interviewing!

First, if you’re not doing behavioral or situational interviewing, then you need to as you move towards agile.  What do I mean by that? Well, instead of asking questions that are based on generic background experiences, place the questions within the context of looking for how the candidate handled a very specific situation in a specific job or role.

For example, here’s a non-situational question: Tell me how you generally handle conflict in teams?

In response to this, you might get a crisp answer with an example, or you might get a more rambling response. The quality of the answer is actually mostly based on how you phrased the question, and not the candidates’ fault if you don’t hear what you wanted to hear.

Here’s a more situational question:  

You mentioned that you left XYZ Company because your boss overworked you and you felt that your interests were not supported. Can you give me a specific project example of where your boss didn’t support you?

After the candidate gives you an answer, the following follow-up question opportunities might expose themselves:

What part did you play in the lack of support? Did you suggest improvement ideas to your team? Project Manager?  Or to your boss? Did you ever “confront” your boss about your frustrations and explore “options”?

As you can clearly see, these sorts of questions start drilling into the specific behaviors that the candidate exhibited in very specific situations. I also like to drill in with follow-up questions. Sometimes, I’ll say something or interpret and answer quite extremely—just to see how they react to the question.

It sounds like you really didn’t make much of an effort to challenge the status quo in that example. Instead you sort of acquiesced into complaining. Why was that?

One important note in this style is the effective use of silence. You have to realize that these questions are hard, and that candidates need to “search their database” for a context-based answer. So patience is required. As is silence, as the candidate thinks of an answer. Don’t try and fill the void of silence. Instead simply wait for the candidate to formulate and deliver their answers.

Given the focus of this blog series, you’ll want to explore their views towards agile methods and some of the discreet areas that are important therein. Just to get you thinking of examples, I like to explore some of the following topic areas in our agile interviews—

• Teamwork:  How do they feel sitting closely together—in co-located spaces? Or about working in pairs? Do they see themselves as good teammates and what are the attributes of a good teammate? Explore their feelings around servant leadership, the golden rule, etc.; Are they good followers and leaders—why?
• Ideation:  Do they exhibit high initiative and high creativity? How do they engage the team in exploring their own ideas? In listening to others? Have them give an example of when they followed a direction that wasn’t theirs—how did that work for them?
• Courage:  Explore their ability and willingness to challenge team members on their approaches? About how they’ve kept the bar high within their teams? Explore their willingness to engage me and other leaders—to tell me when they think I’m wrong? Do they accept responsibility for their own mistakes? Have they ever “apologized” to their team for something?
• Work Ethic:  Do they work hard (not in hours only) but in effort/focus? Do they expect the same from their teammates? What do they do if they don’t get it? What if one of their teammates needs help and they’re behind schedule on their own deliverables—do they help out?
• Quality:  Do they actively engage in quality and testing? Do they serve as a model or champion within their team? Have a whole-team view to quality? Explore how many bugs are acceptable in a project and/or release?  How many sprint escapes are ok? Finally, have them explain agile done-ness and what it means to them?
• Business:  Do they partner with the business in driving a focus on high-value features first? Do they actively engage the business? Do they listen to the business priority and make value based trade-offs? Do they know how to write good User Stories—and have they? Get a few examples. How have they made the “business case” for a story they wanted to get done?
• Personal:  Are they pragmatic or a purist? How do they handle conflict? Do they gold-plate their work? And do they understand the notions of good enough and just-in-time? Do they have a sense of humor and don’t take themselves too seriously? Would they be fun to work with?

So in this post, I emphasized the situational side of interviewing. Please don’t think this is simply FLUFF. As I said in the beginning, I truly believe this is the most important part of your selecting and building high performance agile teams. Do not short shrift or underestimate the value of your conversations with potential team members. It makes all the difference!

In my next post, we’ll explore an interviewing technique called Auditioning that extends much of what I’ve said here…

In my last post I tried to set the stage surrounding some of the differences that Agile teams have when compared to traditional teams. It was important to establish a bit of a baseline, because the differences truly matter.

The differences don’t only translate into technical skill differences, but they also fall into the area of “soft skills” and collaborative behaviors. We’ll examine each in turn.

So, how does Agile change your Technical Interviewing? You still need to technically evaluate each candidate. In this case, if you have an already formed team, then the team would be mostly responsible for interviewing their potential teammates. If you are forming a new team, you’ll need to devise a way for quality technical skill interviews to occur.  

Hard Technical – Developer Skills

There are a few key skill differences to look for. First, you want to ensure that your candidates are comfortable developing code that is well designed and easily maintained. This follows the Agile principles of Incremental & Simple Design. Quite a few software architects and developers say they can build incrementally, but it’s truly hard to do it and demonstrate working code at the end of, let’s say, a 2-week iteration.

Also critical are the Agile practices of Refactoring and Reduction of Technical Debt. You’ll want to explore design patterns with candidates and explore how well they understand incremental design. Explore their courage when it comes to dealing with “business pressure” on schedule vs. proper design. How effectively do they negotiate that pressure and still maintain design integrity OR reserve time for later refactoring of trade-offs?

Finally, Agile developers need to “get” testing in their very core—you’ll hear the term “Test Infected” used to represent this Quality First Mentality. Ask them how, where, and how many unit tests they usually write. Ask if they understand the principle of Test-Driven-Development where unit tests are used as a design aid and as a testing artifact. Finally, ensure that they keep their tests, all of their tests, continuously working as they develop more code.  

Hard Technical – Business Analyst Skills

One of the key stretch points for traditional Business Analysts, when they move towards Agile methods, is the fact that requirements are no longer solely completed in the beginning of the project. Nor are they intended to be complete.

Now if you happen to have a BA background you’re head just exploded. What do you mean intentionally incomplete requirements!?!

Agile BA’s need to understand the incremental nature of Agile requirements. Also, how systems are built and clarified by examining running and working software along the path as requirements get continuously refined. They also need to have familiarity with Product Backlog management techniques (from Scrum) and understand User Stories (from XP) as the primary mechanisms for creating Agile artifacts.

One Prime Directive that the BA needs to understand is that writing about requirements is not the goal. Communicating and collaborating around requirements IS the goal. Check this point thoroughly in your interview…or at least whether the candidate has the capacity to change focus!

Another key difference in Agile requirements is determining business value and bundling Customer Acceptance Tests in the requirements. These two key aspects, more than anything else, try to connect the customer to each of the requirements so that the team can better understand the impact and importance of what they’re implementing. Candidates should be able to articulate this clearly.  

Hard Technical – Tester Skills

Testers are challenged greatly in the shift towards Agile methods. Instead of being a “late in the pipeline” verification step, their responsibilities shift towards customer engagement, becoming a Voice of the Customer, and also a Quality Champion within their Agile teams.

Initially, they work with the customer to define and refine requirements early in the process (each iteration). Part of this is simply writing the requirements—so there is overlap in this responsibility with the BA. At the end of each iteration, they execute the User Story & Acceptance Tests to verify each met customer needs. It’s these early definition and late verification steps, on an iteration by iteration basis, that assures the team is delivering quantified value.

You’ll notice that I didn’t say testers—test continuously in the methods. This sort of test it in approach, while necessary to a degree, doesn’t achieve the overall project quality results we desire. The good news is that testers have understood this for years, but have been suppressed in focusing on up-front quality. So, they should be energized by this difference!

Testing in Agility also crosses the boundaries of manual vs. exploratory vs. automated testing. In fact, Agile testers are true generalists when it comes to their efforts. One minute they might be sitting with a developer writing some automated unit tests. Then next, writing automated smoke tests, and then running a few manual tests to gain early feedback. This flexibility and breadth of skill is crucial for their success.

In my next post I’ll focus on the soft skill areas that need attention as you begin to make changes in your recruiting screening and interview processes.

References:

There are two great books I recommend to help improve your interviewing skills & techniques as your reframe towards Agility…

One is Johanna Rothman’s wonderful book – Hiring the Best Knowledge Workers, Techies & Nerds.

And the other is Joel Spolsky’s – Guerrilla Guide to Interviewing.

So you’ve had the interview, but you just can’t seem to get the offer?

This is the story I hear from folks everyday. And it’s no surprise. The job market is very tight and extremely competitive. Companies are taking their time to interview a lot of folks in an effort to find that “perfect” match. Hiring budgets are tight, and companies continually try doing more with less people.

While you can’t change others [people, companies, family members, etc.], you can always try to do something different.

I say go work for free.

"Free?" you say.

Well, not exactly free, though you might find yourself not getting paid for the work you do. But I always like the unconventional approach, the actions that will make you stand out in a crowd.

Let’s face it – the company interviewed you because they have work that needs to get done. The work is piling up or being taken care of by someone working double-time…or a little of both. All I am suggesting is that you offer a one-week, hands-on interview and take on a project. For no cost, you’ll give them an opportunity to work with you and see how you solve problems. You’ll get a view of that company that no other candidate would even dream of getting.

And…you might find yourself getting a job offer.

Think about it.

Has it been a while since you’ve interviewed? Not much time to prepare? Don’t panic. The rules of dating can also be applied to interviewing. 

Do not arrive too early.

Human resources professionals and hiring managers have busy schedules and work by appointment. By arriving more than ten minutes before the meeting is scheduled you show disrespect for their time. If you must, wait in the lobby or your car before going to the interview location.

Do not show your desperation!

Telling the interviewer that you haven’t had an interview in months, you don’t have health insurance, or that you really need this job, is not going to improve your chances. Quite the contrary! If you told someone on a first date that you’re broke, about to lose your house - and car, and you really need to marry them, what do you think are the chances that you’d see that person again?

A proper thank you is always appreciated.

Send a note and thank the interviewer for their time. Have the envelope addressed and stamped before you even leave for the interview, and the moment you get home, write the note. (At the very least, send an email!) This is important because the discussion will be fresh in your mind, and you should reference one or two key points from your conversation. Use this opportunity to reinforce why you are a good fit for the position and how you can benefit the company.

Whatever you do for God’s sake do not stalk the interviewer.

This includes calling and hanging up. Yes, they have Caller ID, and they know it’s you! Nobody likes to be stalked or harassed. When they have news about next steps they’ll reach out to you. If they don’t, you may need to prepare for the fact that they just might not be that in to you. Ask at the end of your interview when and how you should follow up, and do it. If at that time they don’t have any news for you, ask when and how you should follow up next.

We all make bad hires.  I had been recruiting for 5 years when I hired my first full-time babysitter and she ended up failing the background check.  To me, she seemed to have all the right experience and answered all my questions really well. But after all that, it turned out we didn’t share the same value system.  I should have asked more about “her,” than her experience.

So, how can you do this in an interview?  It’s tough…but here are a few tips that might help assess whether you’re making the right hire for your open position.

When looking at a candidate’s communication skills, ask interview questions that have open-ended answers and in a format that requires they explain the situation, what they did, and the outcome.  A key thing to look for is whether they can describe it in a way that you can understand, and whether they are constantly using jargon that your business folks won’t understand.

In assessing problem solving skills, ask them to tell you about a problem and step through how they handled it.  Again, look at how they walk through the problem, describe the solution, and assess the results. 

To see if they are a team player, ask them to describe a really difficult person they worked with and how they handled the situation.  Have them tell you about their current team dynamics and how they could work better (positive/negative? take responsibility for own attitude/actions?). 

You will see a lot of their interpersonal skills throughout the interview, but ask them to tell you about a time when they used humor to diffuse a situation (especially if your team jokes around a lot).

To see if they will give good customer service, ask them to describe a time when a situation did not go as planned and how they communicated the negative news to the client. 

To determine if they have good leadership skills, ask about how they handled a time when they asked a team member to complete a task a certain way and they did it well, but not according to instructions. 

In listening to the responses of candidates above, you will see certain traits come out:    

• Attitude –Are they upbeat and did they have generally positive responses and feelings about different situations? 
• Accountability/Ownership - Do they take responsibility for their tasks, attitude, actions, and results?
• Sense of urgency - Did they arrive on time, ask about next steps, and show interest in moving forward?
• Attention to detail – Are their answers descriptive and thorough without being too much?
• Organized – Do they follow a logical process when describing problems solved?
• Ability to handle criticism – If the situation was negative, did they adapt and learn?
• Flexibility – Were they able to take on new tasks, change direction, and adapt to another’s needs? 
• Honesty/Integrity – Did they resolve their problems with integrity and communicate honestly with others?
• Listening – Did they ask follow-up questions about the job/company etc. that shows they were listening?
• Follow-through – Did they send a thank you note or complete something that you asked for?
• Preparedness – Did they research the company/job/you before the interview and ask relevant questions?

Finally, it is good to understand their personal interests and motivations.  My favorite question of all time – and one that I find hard to answer myself – “If money was no object, what would you do?” 

We have a saying in our business that “there is a seat for every person” (we use a different term, but person suffices).  You could interview all day long, ask all the right questions, and still get a bad hire.  Hopefully, though, when you drill down on their technical/functional skills and you learn what makes them tick, you should be able to avoid the dreaded “90-day action plan” to remove your bad hire and repair your damaged team.   

Good luck!