When building a high-performing Agile team, or any team for that matter, you need to look at people as more than “resources”. If they were just “resources”, their contribution would be merely additive. It therefore always saddens me when I hear managers talk about employees as “resources”. Even more depressing, is when the people making up the organization also talk about their colleagues and themselves as merely “resources”.

All people are different and to build a high-performing Agile team, you need to look at them holistically and how their contribution to team synergy can amplify results. You need to look beyond their domain knowledge and main skills. Consider their qualities, experience, preferences, and diversity. The more complex and uncertain the work, the more diverse the team should be. Having only .Net developers on a team that needs to build an integrated .Net and Cobol solution is a bad idea. Teams also benefit from diversity in life-experience, cultural background, age, problem-solving approaches, social skills, etc.

There are certain working preferences that people have that are a better fit for agile teams than others. Collaboration, short feedback cycles, learning from others, and being part of a team are core Agile values. Agile teams are jointly responsible for results and, therefore, team members need to embrace working together. Attending a morning stand-up or asking/answering an occasional question from a colleague is not true collaboration. Preferably, people need to be comfortable showing unfinished results and truly listen to feedback from colleagues and stakeholders.

In addition to peoples working preferences, you should also look at peoples’ personal traits. Self-disciplined, responsible, curious, and pragmatic people who can take initiative and focus on execution are often a great fit for Agile teams. Agile teams need to be able to respond to change and, therefore, people need to be flexible in the roles they play. One sprint a team might benefit from having a team member focus on developing the solution, and the next sprint working directly with users on refining requirements.

The working preferences and personal traits discussed above are ideal but not necessarily needed for all teams in all situations. When building a team, ask yourself how dynamic the team really needs to be. It is desirable that every team can quickly respond to change, but if a team primarily works on a mature, internal product, the frequency of required change will probably be less than, for example, a team working with a dynamic technology landscape. The maturity of an organization’s business model, staff turnover rate, and customer loyalty can also play a role in how dynamic teams need to be. I always prefer teams to be both efficient (cost of deliverables) and effective (value of deliverables), but sometimes you need to make short-term tradeoffs and focus on one or the other. As a leader, it should then become your long-term goal to help the team develop a better balance between the two.

As a leader, it is your responsibility to set up individuals and teams’ for success in a constantly changing world. By seeing people as individuals and not merely “resources” and focusing on diversity, you increase their balance, creativity, flexibility, robustness, and ultimately their chance of success.

As always, I would love to hear your thoughts using the comments below.

Image credit: unsplash.com

Leave a Comment

4 Comments

  • In-Real-Life it’s very complicated to have specialized groups within the same team, as some ends up as bottlenecks, and others may not have enough… Alternatively we wrote dedicated stories for each group, which seems to work for the dev phase, but mess up PO oriented test & prioritizing and jeopardize jointly responsibility of the result.
    I read your post as we should continue the challenge, and not split the team into dedicated teams 🙂

    • Thanks for sharing Gustav,

      Your take on the issue is something I have seen multiple times and it’s a very real challenge for many teams. The easy solution, from a developer perspective, is to split the stories into technical stories. The problem is, as you point out, that you often loose sight of the business value your trying to create and you also remove encouragement for developers and other specialists to work together. As a leader, you can help the team become jointly accountable by building trust and encouraging constructive conflicts. You also need to allow the team to go slower for a period of time, while they figure out how to work effectively together on the same tasks.

  • Very good point that “the more complex the work, the more diverse the team should be”. Consequently, managers need to spend time grooming the realtions and collaboration between team members – they need to acknowledge their own strengths and the strengths of other team members, and they must be aware how they can use each other in the daily work to create the synergy enabling them to solve complex tasks. Without this awareness, diversity will just lead to frustration.
    I also like the few specific characteristics you point out: “People need to be comfortable showing unfinished results and truly listen to feedback from colleagues and stakeholders”. This is a specific ability that most people will instinctively know if they posses or not (of course, it can be developed through practice and conscious effort) and it’s a good way to test whether a person is fit for a specific position.

    Looking forward to following your work, Martin!

    • Thanks Stine,

      To your point on people being comfortable showing unfinished work, the most important thing managers can do, is to create and encourage an environment where it’s safe to fail.

%d bloggers like this: