Are agile team members different from people on other teams? Yes and no. Yes, because some of the behaviors we see on agile teams are more pronounced than those behaviors on non-agile teams. And, no, because we are talking about people!

But, successful agile team members exhibit certain behaviors more often than non-agile project team members, because agile requires these behaviors to create a successful team and product. If you've been tasked with creating an agile team, what qualities should you look for? Below are six key behaviors people on successful agile teams exhibit. I've also included interview questions to determine if an agile team candidate has what it takes to join a great agile team.

1. People Who Collaborate
People who can work together—really collaborate—are much more valuable than people who need to work alone. But, what does it mean to really collaborate?

The first thing you see in an agile team is that people work together on features. It's common on a non-agile team for people to take features or requirements and work on them alone, but that's uncommon on a well-running agile team, where several developers and a tester or two may work together to make sure they—as a team—have completed a story. You may see several testers working together to develop tests, or (one of my favorites) you may see developers and testers working together to develop the test automation framework for the project team.

The entire team works together to define, start, and finish features. Successful agile teams avoid the problem of having many features started but none finished at the end of the iteration, because they collaborate to complete features.

A question you can ask a candidate is "Think back to a recent project. Give me an example of a time you had to work with other people to make sure that you could finish something. What happened?"

2. People Who Ask for Help
It's not easy for many of us to ask for help. In many organizations, it's not even right to ask for help. Yet, people who can ask for help are people we want to hire for an agile team.

Why is asking for help so important? We all know something about the project, but none of us knows everything we need to know. So, we need to be able to ask for help, and we need to do this from a position of strength—not a position of weakness. On an agile team, it's not a problem to ask for help. In agile, we don't want to incur the delay of people being stuck before asking for help, and it's more important that the team deliver all the features the team committed to at the end of the erasure than that any one person be a hero.

Here's a question you could ask a candidate about his or her ability to ask for help: "Think back to your most recent project. Tell me about a time you did not understand something. What did you do?"

3. People Who are Willing to Take Small Steps and Get Feedback
Agile is all about feedback. We use iterations so we can do something and get some feedback. We build in increments so our customers have a chance to provide feedback on our work to date.

One of the behaviors you want to look for in a candidate is the ability to take small steps and get feedback on whatever work he or she performed. People who seem to need to finish a feature perfectly (whether those people are developers, testers, writers, or whoever) before anyone sees it are not well suited to an agile team.

One of the series of questions you can ask is "Tell me how you like to work. Think back to the last feature you worked on. Did you try to finish the whole thing before you asked for feedback?" Wait for the answer. Now, ask, "Why?" The candidate might tell you he or she had one shot at getting feedback. Or the candidate might say he or she was expected to complete everything perfectly. Now you can ask, "When you work on your projects outside of work, how do you work?"

4. People Who are Willing to Do Something That Is Good Enough for Now
Similarly people who are able to take small steps and get feedback might also be willing to do something that is good enough for now. One of the problems in agile is we don't have time to do everything perfectly at one time. That's why we use timeboxes. We do what's needed for now, and based on feedback decide whether or when to return to it later.

The ability to do something that is just good enough for now and come back to it later, when doing so has more business value, is not a common behavior. You can see this in testers who want the absolute best test system at the beginning of the project. You can see this in architects who want to fully define the architecture at the beginning of the project.

One of the problems of agile is that we cannot tell what will be perfect at the very beginning of the project. Sometimes, we can't tell in the middle either! So, we need to do something that is good enough for now and come back to it later when we will get more business value from focusing on it.

To tell if the candidate has this ability to do something that is good enough for now and to postpone finishing it perfectly, ask: "Tell me about a recent time you did not know everything at the beginning of the project. What did you do?"

5. Adaptable People
In agile projects, as in all types of projects, conditions are not always perfect. We may not have a team room, we may not have acceptance criteria for all the features, and we may not even be able to remove obstacles, but we still have to get work done.

We're not looking for saints; we're looking for people who are adaptable to current conditions. We want people to do the work even with imperfect conditions.

You'll know if you have one of these adaptable people based on the answer you get to the following: "Tell me about a time when you did not have the conditions you would've liked for your project. What did you do?"

6. People Willing to Work Outside Their Expertise
One sign of adaptability is a person's willingness to work outside her area of expertise. I'm not suggesting that people do things that they have no idea how to complete—for example, a developer shouldn't turn into a marketer (unless the developer wants to). I am suggesting that if someone is very comfortable with the database, she also should try to work a little bit in the GUI. If she's comfortable with middleware, maybe she'd like to work a little at the platform level or at the upper level of the application. If she's been an exploratory tester all of her test career, maybe she's willing to try a little scripting. If she's been an automation weenie, maybe it's time to try a little exploratory testing.

We see this willingness to work outside expertise in agile teams when people collaborate to swarm around a feature. People are willing to work outside their expertise but not far from it. To learn more about this ability, ask, "Tell me about a time you took on work to help the team. What was that like?"

A candidate may not be able to answer that question. You may then have to set the context with something like, "We work on things we may not be comfortable with in order to finish a feature for an iteration. Have you ever been in that position?" If the candidate does not say yes, you'll have to ask the question differently. For example, I've had some success with the following: "Tell me about a time you did something you thought was not in your job description. What did you do?"

Summary
These may not be the only behaviors you need for your agile team. Make sure you do a job analysis to see how your agile team is different, and then you'll know the kinds of candidates to consider.