Six Agile Team Behaviors to Consider

People Willing to Work Outside of Their Expertise

A person’s willingness to work beyond his or her area of expertise is an indicator of adaptability. I do not recommend anyone to do things they do not know anything about, a programmer should not become a salesman, for example. I believe that someone good with the database should try to work a little on the user interface as well. If she knows middleware, she might want to do some work on the platform or a higher level of the application. If she’s always been an inquisitive tester, she might be willing to try some scripting.

We see this desire to work outside of one’s area of expertise in agile teams, when individuals work together to rally around a product. People are willing to work beyond their area of expertise, but not far from it. To learn more about this talent, ask, “Tell me about a time when you took on additional work to support the team. What was that like?” A candidate may not be able to answer this question. Therefore, you may need to provide context by saying something like, “In order to complete a feature, we work on things that we may not like. Have you ever been in a similar situation?” If the candidate does not answer positively, you need to rephrase the question. For example, I have had success with the following, “Tell me about a time when you did something that you did not think was part of the requirements of your job. What exactly did you do?”

Key Takeaway: An agile team member should stretch into work that sits next to an existing skill, such as a database developer picking up user interface tasks, rather than into an unrelated discipline.

Adaptable Individuals

As with all projects, things are not always ideal in agile initiatives. Even if we do not have a team room, do not have acceptance criteria for all functions, or are not even able to remove obstacles, we still need to get the work done. We are not looking for heroes, we are looking for adaptable people. People who continue to get the job done despite adverse circumstances. If you get one of these adaptable people in response to the following question, “Tell me about a time when the circumstances for your endeavor were not as ideal as you had hoped. How did you handle it?”

Key Takeaway: Adaptable team members keep delivering when the conditions are imperfect, for example when acceptance criteria are missing or a dependency is blocked, without waiting for someone else to clear the obstacle.

Individuals Who Are Willing to Take Small Steps and Receive Feedback

Agile is all about getting feedback. We use iterations to do things and get feedback. We build in small increments so that our customers can give us feedback on what we are doing. One of the qualities you should look for in a candidate is a willingness to take small steps and receive feedback on their work. People who give the impression that they need to finish a feature (whether they are a developer, tester, or whatever) before anyone else sees it are unsuitable 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. Did you try to get everything done before asking for feedback?” Wait for the answer. Now ask yourself, “Why?” The candidate might tell you that he or she only had one chance to solicit feedback. Or the candidate may claim that he or she was expected to complete everything.

The same habit runs at the code level in test driven development. A failing test comes first, the implementation follows, and feedback arrives in seconds instead of at the end of a sprint.

Key Takeaway: A candidate who insists on finishing a feature before anyone sees it will block the feedback loop that an agile team depends on.

People that Work Together

People who can work together are far more effective than those who have to work individually. 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 functions. It’s typical for employees on a non-agile team to work alone on features or requirements. However, this is unusual in a well-managed agile team, where multiple developers and one or two testers work together to ensure that, as a team, they have completed a story. It is possible to see a group of testers creating tests, or developers and testers working together to create a framework for system testing for the entire project.

The entire team contributes to the definition, initiation, and completion of features. Because they work together to complete features, effective agile teams avoid the problem of having many features started but none completed by the end of the sprint. You might ask a potential candidate, “Think about a recent project you undertook. Give me an example of a moment when you had to work with others to make sure you got a task done. What happened during that time?”

Shared work on a feature is also what makes agile testing possible, because testers shape the acceptance criteria with developers instead of receiving a finished build at the end of the sprint.

Key Takeaway: Teams that work together on a small number of features avoid ending a sprint with many items started and none finished.

Those Who Seek Assistance

Many of us find it difficult to ask for help. However, people who can ask for help are the kind of people we want on an agile team. Why is it so necessary to ask for help? We all know a little 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 not a problem for an agile team. In an agile team, it’s more important to deliver all the agreed-upon features at the end of the sprint than for one individual to become a rock star. We do not want delays because individuals are waiting to ask for help when they are blocked.

Here is an example of a question you might ask a candidate regarding their ability to ask for help: “Think about your last project. Tell me about a moment when you were confused by something. What exactly did you do?”

Key Takeaway: Raising a blocker within hours protects the sprint goal, because an unspoken blocker costs the whole team and not only the person who is stuck.

How Do AI Coding Agents Change Agile Team Behaviors?

AI coding agents make two of these behaviors cheaper and one of them harder. Crossing a skill boundary and asking a first question now cost minutes, while reviewing what the team ships costs far more time than before.

Tools such as GitHub Copilot, Cursor and Claude Code sit inside the editor and the terminal, and the Model Context Protocol lets an agent read a repository, a ticket tracker or a test report directly. A tester who has never written a build script can now get a working first draft of one.

That shifts where the risk sits. The behaviors an agile team needs from its members change in three concrete ways:

• Review over typing: A team member who accepts agent output without reading it moves defects downstream instead of removing them.
• Three failed fixes: Bring in a colleague at that point instead of prompting the agent again.
• Reviewable commit size: A large agent-generated change is hard to review, so split the work into commits a reviewer can hold in their head and keep the feedback loop alive.

The same pattern is visible across AI in software testing, where generated test cases still need a person to confirm that the assertion matches the real requirement. Interview for it directly by asking a candidate to describe a change an AI tool produced that they rejected, and why.

Key Takeaway: AI coding agents lower the cost of working outside a specialism, so critical review of generated code and knowing when to escalate to a human become the agile team behaviors worth hiring for.

People who are willing to do whatever is enough at the time being

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

One of the challenges of the agile approach is that we cannot predict what will be ideal at the beginning of the project. Even in the middle, we can not always tell! So we need to do something appropriate 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 execute something well enough for now without doing it flawlessly, ask, “Tell me about a situation where you did not know everything at the beginning of a project. What exactly did you do?”

Key Takeaway: Good enough for now covers test harnesses and architecture documents that can be revisited, and never covers agreed acceptance criteria or known defects.

Closing

These may not be the only qualities your agile team needs. Make sure you do a job analysis to see how your agile team is different, and then you’ll understand what kind of candidates you should pursue. Track the result with agile metrics such as sprint completion and cycle time, so you can see whether the behaviors you hired for are showing up in delivery.