Hiring Great Agile Teams (Part 3)

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…

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com

Posted in: 
Bookmark and Share

Hiring Great Agile Teams (Part 2)

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.


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.

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com

Posted in: 
Bookmark and Share

Preparing for an interview is kind of like getting ready for a date.

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. 

Asher Date Kept on TalkingDo 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.

About the Author: 

Stephanie A. Lloyd is Strategist-in-Chief, Calibre Search Group, located in Atlanta, Georgia at the intersection of Talent Strategies + Social Media. With more than 15 years of experience in corporate recruiting and executive search, Stephanie works with hiring managers, HR executives, business owners, and recruiting firms on recruitment and retention strategy including how to better utilize social media for talent acquisition and employee communication. Stephanie is a regular contributor to Talent Net Live and The Matrix Wall, and she partners with Todd Schnick to produce the video blogging series He Said, She Said.

Posted in: 
Job Seeker
Bookmark and Share

Hiring the Right Person – Assessing their Soft Skills

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?
  • OrganizedDo 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!

About the Author: 

Chrissy Petri is an Account Manager for MATRIX Resources with 15+ years in the IT recruiting industry in Atlanta. She works with small, medium, and large companies to find IT talent from Help Desk to Programmers to Project Managers and Directors.

Posted in: 
Hiring Manager
Bookmark and Share

Hiring Great Agile Teams (Part 1)

When I started thinking about the title for this blog post series, I struggled with the “hiring who” clause. Is it hiring engineers? Or folks? Or developers? Or agilists? Or testers? You get the gist. And then it dawned on me that none of those was right. While yes, you hire individual contributors for agile teams, you’re really in the team building business when you’re operating within the Agile Methods. So there’s the challenge—how do we hire great members for agile teams?

Well, I’m going to share some advice on this topic over the next few posts. But first, perhaps an introduction is in order.

My name is Bob Galen. I’ve been teaching MATRIX seminars for a number of years. Early on, my focus was on management techniques—technical leadership, team building & hiring, and generic soft skills.

Later, I began to share on the Agile Methodologies. It was a natural progression for me because I’ve been using them since 2000 and I’m a recognized SME and enthusiast in the space. To be honest, I have trouble containing my passion at times so I need an outlet.

And so, away we go…

What’s different about agile teams?

It turns out the answer is subtle. From some perspectives, nothing is different. And then from others, everything changes. The best way I can explain it is to contrast agility against our traditional methods.

In traditional methods, you try to capture the essence of the work in your artifacts. That is, all intellectual property is in the requirements, plans, architectural models and designs—essentially all of the pre-work for a given project. So success is really driven by the quality of the artifacts and the up-front planning. Once you get everything defined, it’s simply a matter of execution. Heck, almost anyone could do that part…

Agile takes an entirely different approach. Yes, plans and artifacts are important elements of success. However, the ultimate element of success is the good people you’ve hired—in other words, Your Team! So what are some of the key characteristics of the team?

Notion of Self-Direction

Well, first of all they’re self-directed. Managers don’t micro-manage. Instead, they supply goals and objectives. That implies that team members have the confidence and skills to work together towards meeting those business goals.  They like working and collaborating in groups. They’re comfortable taking constructive feedback and giving it. Quite often, they work in an open office environment—so there’s a level of comfort working “in open space” that’s required.

I guess gone are the days when developers worked in closed offices and you slipped pizza and coffee under the door periodically to ensure they were working.  And in return, code was slipped out.

It really is a transformation from individual achievement and productivity towards how a team gathers around a business problem. The team then figures out the best solution and how they all play a part in achieving it.

Notion of a Business Partner 

One of the key points in agile teams is partnering with the “business” to ensure that they deliver exactly what the customer needs—no more and no less. The customer is a full-time and welcome member of the team. This implies that we deliver products in small chunks and ask (listen for) feedback from our stakeholders and customers. Then we make immediate adjustments.

It also means that we expose work progress transparently to the customer—in good times and bad. Why? To allow for early adjustments to scope commitments. In the case where we over-estimated the work, and can do more than we originally thought,  we need to advise the customer as early as possible so they can think about the next highest priority.

In the case where we’ve underestimated the effort (imagine that!), we work with the customer to jettison low priority scope in lieu of delivering the most valuable bits. These are not a one-time event, but should occur daily—continuously.

Notion of Quality First

Solid agile team members have come to realize that you don’t test or check quality into a project, application, or program. You build it in. Upfront, and with fairly rigorous collaboration and discussion surrounding trade-offs.

You’ll hear the terms refactoring and technical debt from agile corners. Both revolve around the tendency we have of doing shoddy work in our initial implementations, often driven by time constraints, and then never going back to clean up after ourselves. The drive is always more features and we don’t have time nor the funding for any clean-up.

Well in our community and thinking, we should always have the time to do solid work that is maintainable and maintained!  So agile team members take their professional responsibilities seriously and look to do work that they (and you) can be proud of. 

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com

Posted in: 
Bookmark and Share