How to build a great agile team

The group of talented engineers I currently lead have formed into a great team over the last year. Recently, I’ve been considering what I thought that was down to (as it would be quite useful to know!). Was it simply the somewhat fortunate mix of personalities who were allocated to the project? Was it blind luck? I didn’t think so, and after some deliberation here’s what I’ve distilled my thoughts down to: The six things a team leader should do to build a great agile team…

Six things a team leader should do to build a great agile team

1. Gather the right people

This will seem trite, but the single most important factor in building a great agile team is to gather the right people. Thrusting a random selection of “resources” together is almost certain to fail.

When carefully assembling this group of people, it is not enough to look at the ideals of a Scrum team – that is, it is not enough for the team to be cross-functional, co-located and have their time dedicated to the project. It is also not enough to identify team members by looking at their technical skills or specialisations. Some of those aspects are far, far less important than the attitude, motivation and potential of the people that come together to form a really great team.

Let me Put it this way, I’d rather have a new graduate engineer with a team-centric attitude and a drive to improve in my team, than an experienced developer with vast expertise in specific technical disciplines but who
does not play well with others. I’ve occasionally had to make the call between experience and attitude when assembling teams in the past, and I have never regretted choosing someone with the right attitude.

That certainly isn’t to say that you should populate the team entirely with new graduates who possess a can-do attitude. On the contrary, what you are looking for is the right blend. A mix of skills and experience levels. A mix of introverts and extroverts. A mix of heads-down-thinkers and just-get-it-doners. Overall, you want a group of people who are happy to collaborate and want the team to succeed. What every team member of a great agile team needs is an ability, when push comes to shove, to put team goals above personal goals.

There’s so much more to say about gathering the right people. Mike Cohn talks about “Getting the Right People on the Team” in his book Succeeding With Agile, so I’d recommend grabbing a copy of that. My headline for a team leader or project manager is – think carefully about the balance of the team.

2. Set a clear direction

Go about setting some clear, realistic goals as soon as you can at the start of a new project or the inception of a new team. Including all team members in that process will give those goals a better chance of actually being adopted as a measure of success by the group.

The team may well come up with technical goals, such as “No manually testing will be required to release”. Embrace these targets but be sure to highlight the targets that have been set by the business too. If the project needs to achieve something for it to been seen as a success for the company, this has to be highlighted.

Business goals can co-exist with technical and process goals, but they must be defined in a way that the team and it’s individual members can identify with and get behind. For instance, a usage goal – increase active users of the product by 1,000 – may well be more powerful than a revenue goal – make $100k in Q3. The former focuses on the people actually using the features/stories/fixes that the team work on, rather than the company’s profitability. Profitability for a company is vital, but is not something directly controllable by the team. The team need to feel that their goals are something they can directly achieve through their efforts and influence.

Encourage the team and the business to define goals that are incremental and measurable. Goals should not be a on/off switch, you should be able to gauge and celebrate progress.

3. Call-out your shared values

Help the team be explicit about the values they share or want to aspire toward. As a result of establishing those values, you can generate a collection of effective behaviours that can act as team touchstones, encouraging team members to keep true to their ambitions and vision. Get everyone on the team to agree to ‘sign-up’ to these values. If there are objections, try to reach a consensus or compromise, if you can’t – move on and return to that proposed value at another time. The whole team needs to agree to these values up-front.

These set of values are often called a team’s working agreements. However, they need to go beyond the prosaic “We have stand-up meetings every day at 10am”. They should encourage behaviours that the team would otherwise not undertake. For instance, the team may decide they believe in reducing Technical Debt, so an agreement to adopt the Boy Scout Rule could be a catalyst to achieving this and a constant reminder of their shared attitude towards problem legacy code.

A team member of a great team should be able to highlight when a shared value has been ignored or forgotten. They should be able to do so without fear of reprisals or of causing hurt. So in my example, if during a code review a developer notices that their colleague has neglected to tidy-up anything in the legacy code they altered, the reviewer should be able to call-out that the Boy Scout Rule has been ignored and fail the review. Doing this may not always feel comfortable, but the team made a pact to keep to their shared values. As Patrick Lencioi writes in his fantastic book The Five Dysfunctions of a Team, team members need to trust each other, engage in healthy conflict and hold each other accountable. If you are in the business of leading teams and have not read that book, you should definitely do so (there’s even a graphic novel version!).

4. Get the team to work together

Encourage the team to ‘swarm’ on as few pieces of work as possible. If there are four developers in the team, don’t work on four distinct features if you want to build a great team. Work on a single feature. That feature will be better understood across the team, better architected, more likely to actually work and will be ready to deliver to users more quickly (as the team will have one thing finished rather than four things in progress).

Working together will reinforce the team’s shared values and behaviours. More importantly, it will mean that everyone has skin in the same game. One person’s blocking problem is everyone’s blocking problem. Similarly, one person’s success is everyone’s success. Contrast this to when numerous pieces of work are underway simultaneously – one person in the team can be struggling with a difficult feature when the rest of the group are happily making progress. That approach fosters divisions within the team and great teams don’t have divisions.

Team leaders can encourage the team to work together on stuff by selling the above benefits. They can then implement a small work in progress limit which will force team members to join-in with work already in progress once that limit has been reached. To some members of the team, this will feel like an inefficient way to work. Acknowledge that argument (even if you disagree with it) and challenge the team to try it. They might need to think hard about how to make work parallelizable but after a few sprints of pairing, learning and finishing stuff, ask the team to reflect on whether this new approach was beneficial overall.

5. Continuously improve

As I’ve written before, I believe the drive to inspect and adapt is the most important concept to have been popularized by the agile software development movement. This essence of this idea is that “we will always know more about the project in the future than we do right now”. The responsible response to that is to build in regular, frequent feedback mechanisms to our development process to be able to take stock of, and respond to, our improved understanding.

Taking time to reflect on what has happened on a project and making things better is also a key part of building a great team. Team members need to be able to highlight problems that have impeded, disrupted or upset them. They then need to be given the opportunity and the permission to resolve problems or take steps to avoid issues arising again. The team is self-repairing, which leads to a proactive attitude.

In my view, the best way to ensure that a team takes the time to continuously improve is to have regular, frequent and engaging retrospective meetings. If you want to do that, I’d recommend reading Esther Derby and Diana Larsen’s Agile Retrospectives book.

6. Celebrate success

Being in a great agile team should not be a thankless task. When things are going well, reflect on this with the team and take the time to enjoy it. When team members pull-out all the stops to do great work but receive no recognition, their motivation can be eroded and their commitment to the team’s cause may waiver.

Regular, frequent retrospectives meetings should include time to highlight team and individual achievements. Review (aka Show & Tell) meetings should emphasize good results and happy customer feedback.

Celebrating good work that has been achieved together, helps to reinforce the feeling that you are part of a great team. If you feel part of a great team, then you probably are.

Epilogue

In the above article, I tried to define what a team leader should consider in order to increase the likelihood of building a great agile team. I was trying to keep each point concise but each section could easily be a sizable article on its own and I’ve probably been a bit more verbose than I planned to be. However, I think if you give some concerted thought to those six aspects when you are assembling a team you’ll give yourself a good chance of building a great agile team.

What do you think? Did I miss anything or include something you totally disagree with? Add a comment and let me know.