… that is what I pay attention to when building teams.

This text may be universal, but I put it in my professional environment, i.e. teams implementing IT projects in the Agile culture. I will focus on three main values ranked by me in order of importance:

• possibilities (abilities),
• commitment (willingness),
• and skills (knowledge).

Many people (PM, HR) find this order strange because they focus primarily on the skills and experience. This approach is caused by the knowledge assessment system built into us since primary school. The second reason is the short-sighted politics of the here-and-now company’s needs. However, transferring this approach to team building can reduce the potential value of the product. A unique person’s talents may be missed.

The reasons for the proposed criteria and their order are obvious:

• a capable and willing person will learn quickly (especially in a scrum project),
• a skilled but less capable person is less able to adapt (which is particularly important in Agile),
• a skilled person with abilities but without commitment is passive and this is a problem for the rest of the team and the Scrum Master.

I write about it in both contexts: building the existing team and expanding with new members. When entering an existing team, cracks are visible at first sight. One of the strongest cracks is noob vs. senior. This is the ideal situation if the noob has great potential. If it is possible in terms of chemistry, just try to pair them up. This creates an atmosphere of improvement and instantly boosts morale. It’s a well-known move and probably many of you use it. In this way, we will build an incredibly lasting relationship like a “master with padawan”. This is a great way to build a long-lasting team relationship that will remain longer than one project.

However, few Scrum Masters reach HR departments with this message before the recruitment finalization. The most common situation is the HR department operating in an uncoordinated manner throwing in the new ones “because this is what we were told to do”. I support the recruitment carried out by the team itself because it is the team’s competencies that “the new guy” is to fulfill. The recruitment process conducted by HR in consultation with the team gives much better results. Also, it often progresses faster, because the automatic rejection of candidates due to the lack of the required experience, supported by years of work, is pointless in many situations — it misses talents.

PS. Never, ever do this, if you don’t have at least one really strong developer in the team.