How to Build an Agile Team

More than any other development process that you’ve probably ever worked under before, Agile puts the emphasis on team work. An Agile team is expected to be self-directed, to work together and organise their own time.

Agile emphasises employee creativity and decentralised hierarchy by placing the emphasis squarely on the team; together they must fulfil their sprint goal with effective team dynamics crucial to their success. The team should be the centre of everything and there is no place for heroes, or alternatively, for anyone who doesn’t pull their weight.

Agile is about team participation, responsibility and recognition.

The Ideal Team Mix

Steve Martin of describes the perfect Agile team member as someone who has High Capability and High Willingness; namely, someone with the technical skills needed to do the job and the willingness to sign up to the values and principles of Agile such as working as a team,  responding to feedback, collaborating and more.

I like his description; it works well.

He also makes the point that a team member with Lower Capability but High Willingness can still succeed, as long as you consider their training an investment in the future. Indeed, these people will often do better than someone of High Capability but Low Willingness; it’s not often that you can turn the latter around.

I’ve seen this happen. It doesn’t matter how highly skilled a team member is if he or she won’t pull their weight or is uninspired; they’re going to do little work and chances are the tasks they do do will be poor.  Even worse, and I have struggled with this as a leader, their negativity will be like an infection to the rest of the team, contagious and energy-sapping.

Dealing With Problem Team Members

The best way to deal with this team member, if you can’t motivate them via recognition, is to move them – or the entire team — to put like-minded people together or, at a push, to retain their skills and services as a consultant where they can’t impact on morale but must do the job if they want to get paid. Of course, in some cases, letting the person go entirely will be the best option.

As well as the dysfunctional employee, another team member that can be hard to deal with is the overachiever or, as I sometimes secretly like to call them, the type A employees. This person is usually very skilled and very willing (so exactly the type that should fall into our ideal mix) but they feel the need to constantly fire fight and ‘rescue’ everyone, usually in return for individual recognition. Any time the team hits a snag, they’ll usually be the one to jump in there and do the work themselves.

The problem with this type of person is that they may genuinely not realise that they are doing something wrong; they may think they are helping. Agile, however, should be all about the team and such a ‘hero’ – or anyone who gains such constant individual recognition – only serves to demotivate the rest of the team.

The best way to deal with this person is to explain to them that such ‘rescues’ do not help the team as a whole work through their problems; you could even point out that they could be directly impacting their ability for advancement because they make it seem as if no one else can do their job.

How to Build The Team  

The best way to build an effective Agile team, therefore, is to choose the right people. That process starts at interview, so make sure your interviews are tuned to identify the people with the right technical skills AND the right ‘people’ skills. Your skilled developers will also ideally have prior experience working on a team.

Communication should also be encouraged; open offices without cubicles are often the best environment for interaction, and management should make it obvious to all what characteristics are prized by the company.

Finally, in order to allow your team to grow, you should allow them to fail – or namely, to teach them that ‘failure’ is never the end but merely an opportunity for learning.

Share this Post

Leave a Reply

Your email address will not be published. Required fields are marked *