Six agile team behaviors to consider

Do members of agile teams differ from members of other teams? And yes and no. Yes, because some of the behaviors we observe in agile teams are more pronounced than in non-agile teams. And no, because we are talking about persons.

However, effective agile team members exhibit certain traits more often than non-agile project team members because agile requires these behaviors to create a successful team and product. What characteristics should you look for in an agile team? Below are six key habits that successful agile team members exhibit. I’ve also included interview questions to help determine if an agile candidate has what it takes to join a strong agile team.

People who are willing to work beyond their expertise

A person’s willingness to work outside his professional field is an indicator of adaptability. I don’t advise anyone to do things they don’t know anything about. a programmer, for example, should not become a salesperson. I think someone good with the database should try to work a bit on the user interface as well. If he knows middleware, he may want to do some work at a higher level of the platform or application. If he’s always been an inquisitive experimenter, he might be willing to try out some scenarios.

We see this desire to work outside of their professional field in agile teams, where individuals work together to come together around a product. People are willing to work outside their professional field, but not far. To learn more about this talent, ask: “Tell me about a time when you took on extra work to support the team. What was that like?’ The candidate may not be able to answer this question. Therefore, you need to provide context by saying something like: Have you ever been in a similar situation?” If the candidate does not answer positively, you should rephrase the question. For example, I’ve had success with: “Tell me about a time when you did something you didn’t think was part of your job requirements. What exactly did you do?’

Adaptable individuals

As with all projects, not everything is always ideal in agile initiatives. Even if we don’t have a team room, don’t have admissions standards for all functions, or even if we can’t remove barriers, we still have to get the job done. We are not looking for heroes, we are looking for adaptable people. People who keep getting the job done despite adverse circumstances. If you get any of these adaptive people in response to the following question: “Tell me about a time when the circumstances for your endeavors were not as ideal as you wanted them to be. How did you deal with that?”

Individuals who are willing to take small steps and receive feedback

Agile is about getting feedback. We use iterations to do things and get feedback. We build in small steps so our customers can give us feedback on what we’re doing. One of the qualities you should look for in a candidate is a willingness to take small steps and get feedback on their performance. People who give the impression that they have to finish a feature (whether they’re a developer, tester, or whatever) before anyone else sees it aren’t a good fit for an agile team.

One of the questions you might ask is: “Tell me about your work style. Think about the last project you worked on. Have you tried everything before asking for feedback?’ Wait for the answer. Now ask yourself, “Why?” A candidate may tell you that they only had one chance to ask for feedback. Or the candidate may claim that he was expected to complete everything.

People who work together

People who can work together are much more productive than those who have to work alone. But what exactly does it mean to truly build a team? The first thing you notice about an agile team is that individuals work together on features. Non-agile team members typically work alone on features or requirements. However, this is unusual in a well-managed agile team, where several developers and one or two testers work together to ensure that as a team they complete the story. It is possible to see a group of testers creating tests, or developers and testers working together to create a system test framework for the entire project.

The entire team contributes to feature definition, launch, and completion. Because they work together to complete features, effective agile teams avoid the problem of starting multiple features but none of them being completed by the end of the sprint. You can ask the potential candidate: “Think about the last project you undertook. Give me an example of a time when you had to work with others to make sure you completed a task. What happened during that time?’

Those who seek help

Most of us have trouble asking for help. However, people who can ask for help are the kind of people we want on an agile team. Why is it so important to ask for help? We all know a little bit about the project, but none of us know everything. We need to be able to ask for help from a position of strength, not weakness. Asking for help is no problem for an agile team. In an agile team, it is more important to deliver all the agreed-upon features at the end of the sprint than for one individual to be a rock star. We don’t want delays as individuals wait to ask for help when they’re stuck.

Here is an example of a question you can ask a candidate about their ability to ask for help: “Think about your last project. Tell me about a time when something confused you. What exactly did you do?’

People who are willing to do whatever is enough for the moment

People who can take small steps and get feedback may be willing to settle for something that is good enough for now. One of the problems with being agile is that we don’t have enough time to get everything done at once. That’s why we use both soft and hard schedules. We do what is needed at the moment and then decide whether or not to come back later depending on the feedback. It’s unusual to be able to do something well enough right now and then come back to it when it has greater business value. This may be the case with testers who want the best test system at the beginning of a project. This may be the case for architects who want to describe the architecture in detail from the beginning of the project.

One of the challenges of an agile approach is that we cannot predict what will be ideal at the beginning of a project. Even in the middle, we can’t always tell. So we need to do something relevant first and come back to it later when we can get more business value from working on it. To find out if a candidate can do something well enough so far without doing it flawlessly, ask: “Tell me about a situation where you didn’t know everything at the beginning of a project. What exactly did you do?’


These may not be the only features your agile team needs. Make sure you do a job analysis to see what makes your agile team different, and then you’ll know what kind of candidates to pursue.

Leave a Reply