Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Building an Agile Team

Building an Agile Team

Leia em Português



Building an agile software development team is not as easy as it seems. Many managers and team leads hire technically capable people, throw some form of an agile process at the team, and hope that everything works as well as the literature says it does. This approach is not only unrealistic, but it is prone to failure. This article will describe the components of a successful team and how we built this team.

Components of a Successful Team

A successful agile software development team is made up of skilled developers , has established team values, has good communication, and is always looking to improve. While having every one of these components isn’t absolutely critical for success, having all of them will make the road to success much shorter.

Core Principles

Everyone has an idea about what kind of culture they want to establish for their team. Unless a manager is hiring people that he knows well, turning the vision of a culture into reality is very difficult. We recognized early that the characteristics that were important to us included having a customer perspective, collaborating effectively, managing by fact, and focusing on execution. A team that embodied these principles would be well positioned for success. Members of a team that embody these core principles exhibit a number of good behaviors. Some of those good behaviors are asking questions of customers, thinking like customers, being willing to ask for help, being willing to help others, making decisions with concrete facts instead of personal opinions, and striving to ship finished code.

Effective Communication

Effective communication is critical for success. One of the most effective aspects of communication is to be face-to-face with people. It is much easier to work out ideas when people are located together. Another critical aspect of effective communication is focus. Conversations are not productive if they don’t have a well-defined topic that the participants stick to. A third essential element of effective communication is keeping the conversation focused on facts and ideas. Conversations can quickly degenerate to fights and turf wars when personal opinions take the place of facts and ideas.

Good People

The most important aspect of a successful team is the people. A software development team needs talented people. Skilled developers are required to build complex systems using new technology. Building these complex systems can't be done by one or two people. A team is necessary. Therefore, the developers that are needed must also be skilled in working on a team.

Constant Improvement

We knew that we would fall down a lot as we built a new team and created a new system. The difference between a successful team and a failing team is the learning that happens from these mistakes. Progress can only be achieved by reviewing past failures and making necessary improvements.

Building the Team

Communication Focus

From the inception of our company, we have focused on communication. The physical layout of our office is open. The development team sits in a large open room. Each developer has his/her own desk, and they are grouped in such a way as to facilitate communication. This open environment makes communication much easier because people can't hide out in cubicles and conversations are "public." (It is important that everyone act civilly and professionally so that this environment doesn't become overbearing.)

Establishing Core Principles

As we built the team, we realized that we need to codify the characteristics that we wanted the team to embody. We initially thought that day-to-day interaction would infuse the team with the characteristics we were looking for. Capturing these characteristics and socializing them with the team was necessary in making sure all team members had the proper focus on the values we felt were critical to success. Codifying the characteristics that we wanted the team to embody was a stark realization for us. One realization was that some of the current team members didn't embody the characteristics. We went to great lengths to work with these team members to learn and exhibit the characteristics. Some team members responded very positively, and some did not. In some cases, we had to remove people from the team. The second realization for us was that our interview process wasn't filtering the types of people that we wanted. Our early interviewing process focused very heavily on the technical skill set of candidates. Our selection process looked for the most technically skilled people. This criteria brought us very bright and capable developers, but it didn't always bring people that thrived in our team environment.

Interview Process

Finding technically capable people that fit with an existing culture is tough. On one hand, having objective measures of a candidate helps to quickly filter a candidate pool. On the other hand, purely objective measurements don't capture the "soft" skills that help someone function in a team environment. We struggled with how to probe these areas effectively and efficiently. Our current interviewing model is a multi-stage process. The first step in our process is a phone screen. Phone screens give us a quick way to introduce our company to a candidate and to probe the candidate at a high level. In the phone screens, we cover some basic technical abilities, thoughts and understanding on agile development, and some level of personal introspection. By touching on these areas, we can tell if someone will not function in our environment. If the candidate isn't filtered out during the phone screen, we schedule an on-site interview. This interview is broken up into three segments: technical, process, personal. For each segment, we assign at least two team members so that a majority of the team gets to interact with the candidate. The technical portion of the interview focuses on raw technical ability and includes a hands-on programming exercise. The process portion gets into philosophies on testing, problem solving, and pair programming, among other topics. The personal section looks at conflict resolution, personal motivation, and general mental stability. We've found that this process works very well. If we get through all three segments and there is no hesitation about a candidate, the candidate will work well in our team.

Process Improvement

Process improvement is key to building a successful software development team. We look at process improvement not just from the processes used to write and deploy code, but also processes used to prioritize work and hire new employees. One mechanism that we use for improvement is what we call a "3x3" review. With the entire team gathered together, each team member must come up with something positive from the past three months, and something negative from the past three months. Each team member then gets three votes each for the positive group and the negative group. Those votes are distributed to each listed item. When the review is done, we have a high-level view of what the team sees as positive attributes and what the team sees as needing improvement. This perspective helps keep the team aligned with the stated team characteristics. Another area of process improvement for us has been the interview process. As our understanding of agile development techniques matured, so did our need to find people that were not only skilled technically, but skilled in functioning on a team. Over the course of about eighteen months, we refined and perfected our interview process to a point where we know we won't pass on a candidate that would not thrive in our environment. This improved process gives us a much greater confidence in the people that we hire. We have had to find a balance between executing our existing processes and continually improving the processes. Whenever we experience pain in our processes, we take a little time to evaluate the pain. If the pain looks systemic, we try to identify incremental changes we can make to improve our process. If the pain is not systemic, we usually take a wait-and-see approach before making any other changes.


Over a short span of time, we've learned some valuable lessons for building a successful agile development team. Establishing team values and adhering to them has helped us build a successful culture and refine our interview process. Facilitating good communication has removed obstacles that hinder many teams. Refining our interviewing process has helped us identify qualified developers that will mesh well with the existing team. Reviewing our existing processes has helped us to improve the team on a continual basis.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Communication is where most companies fall down

    by Robert Dempsey,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great post Darren. It's interesting to see how you've used an Agile approach to hiring as well as with your teams and development processes.

    I've found that communication is where most companies fall down. Not necessarily in the amount of communication, but how communication takes place. For instance, I had a developer look at their PM tool and tell me that to him it's plain as day, so why doesn't the CEO understand what's going on. After some discussion, I told him that perhaps the CEO just needs to see the data presented in a different way. He reformatted things, and the CEO and he got on the same page.

    Communication is at the core of Agile and everything we do as people. Ensuring that the right type of communication within the team, to external stakeholders, and to the world are all critical to the success of the team and a company.

  • Re: Communication is where most companies fall down

    by Ravindra Rawat,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In my experience it is most important to hire self organised and motivated team, where there are no managers. Big companies try to mix agile with "Control" by hiring mix of developers in order to reduce costs. Which i believe does not work out.

    Though hiring experienced guys have own set of problems with egos coming in after a while.

  • Re: Communication is where most companies fall down

    by Robert Dempsey,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Ravindra: working with developers or designers means you're going to be dealing with egos, only moreso with very experienced people :)

    I agree that if you have a team of highly self-motivated people that direct managers are unnecessary. Finding the people that fit that bill though can be the challenge.

  • Re: Communication is where most companies fall down

    by l l,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    Lets change point of view for a minute ...

    How talented developer can find truly agile team?
    How can developer interview the company to be sure that it shares his values?

    During my few years career I have seen that most of the companies have very high expectations from candidates (like mentioned in this article) and then it turns out that you are pushed into hopeless situation from which you can escape only by changing the job. Probably you lose a year to realize it since at first you will be trying to improve things.
    Of course you can always stay and watch how your values die.

    It is very interesting that there is so many talks about Agile ... but how many agile teams we have?
    Maybe I'm not in right place on the Earth ... is there any agile team in Europe? ... any ... ? I haven't seen so far.
    Maybe we only like to thing that our team is agile ... it would explain why I haven't seen such.
    Or maybe the "Agile team" is like "peace on the world", the rules are damn simple but people's greed makes it damn hard to achieve.
    Or maybe I simply don't understand what agile team is.

    Probably it is completely unrealistic but I wish that every talented person finds she/his truly agile team.


  • Re: Communication is where most companies fall down

    by Robert Dempsey,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    To the last poster, I have sympathy for your situation. Perhaps Agile teams are much easier to find in the U.S. I know of a number in the UK as well. I can assure you that they do exist and are quite people oriented.

    Good luck in your search or quest to change the paradigms of those around you.

  • Re: Communication is where most companies fall down

    by Adron Hall,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The other thing is, finding ways to NOT have managers directly over a self-motivated and self-directed team. In the rare occasion that a team like that can be formed - often their productivity and quality is greatly diminished by a direct, or worse a micro manager type.

    I hate seeing great teams become no more than an average team because of bad management, and I've seen that before. Absolutely bad for morale.

  • have learned a lot, thanks

    by Jun Ran,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It took me some time to look through this article, I think the time is worth.

    I think the most difficult part is to "Establishing Core Principles", any better idea on this?

  • Re: have learned a lot, thanks

    by Darren Hale,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What do you find difficult about establishing core principles? If I knew where you are having difficulty, I may have some suggestions.

  • Re: Communication is where most companies fall down

    by Sorin Maier,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There are two points of view of Agile, one of the developer and one of the management. A company can say that is an Agile company if the two are similar and are applied. Otherwise sooner or later both sides will loose motivation and will produce poor quality products.

  • Re: have learned a lot, thanks

    by Oliver McPhee,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Darren,

    What 'characteristics' do you believe are important for agile teams?

    I distributed a model on the agile manifesto to my team...
    Agile Manifesto Model

    and then tried to assess the project retrospectively with this model:
    Evaluating your Team Agility

    But i'd love to hear more on your experiences of what characteristics were halting your teams agility & what you did to solve them...

  • Effective interview process for the agile team

    by Murry Li,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great post Darren. I have learned a lot from your article. Effective interviewing process and good communication are the key points for building a successful agile development team. Based on your statement, there are three important interview steps to select valuable agile team members: technical, process, personal. These interview steps not only mentioned the requirements, but also provided details about how to become a valuable agile team member. The agile team members should be a T shaped person. They need not only very professional knowledge in a specific field, but also have the ability to learn and apply knowledge across disciplines. Therefore, the agile team is always learning and looking to improve.

  • Division of responsibility - what do you think?

    by Alissa Hackett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You mention good people. What I love about Agile is the thing we communicate. And even not perfect workers finally become 'good' if they have a little willingness to listen to the things other say to them. More, I noticed that letting people being responsible for things makes them better workers. I know it may be somehow dangerous for a team leader to let others decide about some things, but my intuition was that it is worth trying and... it worked :) I was very happy when I met article that validated my observation ;) Will you write something, Darren, about your opinion on this subject, division of responsibility when building a team?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p