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