The process of forming the team, it’s stages, team roles which should be represented in a team and many interesting issues about team coordination, cooperation, communication and productivity. All of that was discussed during agile community meeting, which Y Soft was hosting last week in Brno office. In this text I want to highlight most interesting issues we have discussed and found ways hoe to handle it.
Introduction
Short introduction by Michal Vallo was about Tuckman’s stages of group development as life-cycle of team construction and Belbin Team Roles as guide to what characters should be included in each team. Later, each participant propose one topic to be discussed, then everybody vote for the one which he likes. I will present three of them which were discussed the most.
Need of Junior/Senior positions
Team consists of different roles and people. One of way how to differentiate team members is usage of Junior and Senior labels. There were many interesting inputs to this topic.
One of the opinion reflected in real company policy was to remove these formal roles. Reasons to do such a thing are more. There is no race in a team to reach senior position. If starting new project and forming new teams, you will prevent situation with low interest in junior positions in a team. But you still have to differ skills and knowledge, reward courage and motivation. It’s should by done by assigning responsibilities, competences, work tasks with different difficulty. And do not forget about money, company benefits and other materialistic stuff.
On the other hand, especially bigger companies has defined career paths, so they need to differ positions on formal level. It also works if these career paths are well defined and they are not limited by project budget or head count calculated on HR. Because there was also one case discussed, where team is limited by budget and even they had chance to hire great senior guy, they couldn’t because of restrictions on number of senior positions.
Low performance of one member in a team
An interesting discussion was about dealing with low performance of one team member, who is lowering teams overall performance. Well working team should identify such a member itself without intervention from higher positions. Move to another team, relocate to another department or fire him are another “simple solutions”.
But what if this member is e.g. external contractor and you cannot get rid of him like this? Again more working solutions were discussed, but think about two types of people. Ones who will get better if you will push them and ones who are too lazy or incompetent for this work type and load. For the perspective ones, motivation is the key. If direct motivation is not successful, try to do it other way. Make them work in pairs with team members which are more productive, make them responsible for something and force them to present work results to the team e.g. on daily stand-ups. They will be shamed maybe, but it should show the difference. For the lazy ones, try to assign them work tasks which are easier, maybe not popular, or just ones that are the cheapest in case they will screw it.
But do not forget. That it’s not only about performance. Team member with lower performance can have e.g. greater social influence for the team, so it’s affecting the team performance also.
Team motivation
How to motivate team and its members to perform better? In the beginning I want to explain difference between motivation and stimulation, because both approaches were discussed. Motivation refers to the will to act, work, create, etc. On the other hand, stimulation deals with encouraging on an initial effort or in supporting an already existing action. Most of discussed motivation practices were:
- Allowing self-development of team members, based on their will and needs of the team
- Giving challenging and interesting task to team members
- Take inputs from team members seriously, try to give valuable feedback
- Trust the team and let them make decisions, give responsibilities to each team member
If there are some activities in the team like supporting the product or bugfixing, which are not as popular as e.g. new development, distribute these type of tasks over the whole team by rotating engineering role every iteration or distribute it evenly across all team members.
It looked like everybody has took something from this meeting, and I am looking forward to another interesting topics to be discussed in further community meetings.