Teams

22/12/2014 by Christian Kram | Filed in basketball, testing | Comments Off on Teams

I stumbled across this on twitter today:

 

While I agree, I think there is more to it. I have been a basketball coach for almost 20 years and had my share of teams. Some very talented, some not that talented. Some very successful, other not that much. Talent does not guarantee success when talking about teams. One year I had a really talented team poised for promotion, but we failed. The chemistry stunk. Another year we were the underdogs in a qualification tournament, which we won, because we had a goal and determination.
From my experience there are five reasons for teams being successful:

  • A common goal
  • rules
  • role awareness
  • dependency on each other for reaching goals
  • awareness of this dependency

I did not include talent or skill on purpose as this is rather something influencing the goal but nothing influencing team success. These lessons learnt in basketball do apply to software developing teams (or any team actually) in my opinion. Let me elaborate on those points a bit more.

A common goal

Actually it is about several goals. Long-, mid-, and short-term goals are needed not just for every individual, but for the team. And everyone needs to agree with these. Oftentimes not everybody agrees, which leads to discussing the same thing over and over again (we all experienced that, don’t we?). The ones in charge (may it be the coach, the project manager or the team) needs to act quickly in these cases and has to get that person on the same page (and convincing certainly works best here). If the person for some reason can’t agree on the goals it is either time to redefine goals if valid points are proposed or person and team need to part ways as neither will be happy or successful (no, I don’t mean fire here, a change of team or project is more than sufficient in most cases). If everybody is to agree on the goals, who is to define them? Long-term and to a certain extent midterm goals are mostly business goals which are given by management or project management. Some midterm and most short-term goals should be coming from within the team.

Rules

Teams need to have a certain set of rules to play by. Of course there are rules you cannot set up yourself. If your company working hours are 9 to 5, well, then you can’t simply work 10 to 6. But these exterior rules are more or less a given framework. More interesting are interior rules. Rules, often unspoken, that teams set up for themselves. I was on a team once that tried to avoid English terms whenever possible, which took new team members some time to get used to. Most often this point works out pretty well anyway. It is important that the rules apply for everyone equally, or resentment will start to appear quicker than you can spell that word.

Role awareness

A team needs different roles, be it the product owner, scrum master, developer troika on scrum teams or goalkeeper, defender, midfielder, forward scheme on football teams. I mentioned above a basketball team of mine that utterly failed. One of the reasons was that some team members did not really agree with the position they were supposed to play. They did not act according to the role that would have been necessary for the team to succeed. A way better example is a scrum team I was on. Almost every team member used to be a project leader before, but everyone agreed on their roles and the project went great. Everyone knew his role and acted to it. Last but not least: teams are not necessarily on the same hierarchical level: Of course coaches in sports or project managers in work life are part of the team. Their role may be different, but they are not outside!

Dependency on each other for reaching goals

This sounds simple, but still needs to be stressed from time to time. E.g. a tester can only use his skills for the good of the team if there is something to test, which of course can only be there if it has been developed. A project manager needs developers and testers to get a proper product. A football team needs a goalkeeper to keep a clean sheet. A hand is nothing without a thumb. You get the point…

Awareness of this dependency

Well, this is knowing what is described above. Even if a product manager can deliver a product (quite some can do so), it is not his task or role. He needs to trust the team to do it, just as the team may need the project manager to keep strategic business discussions away from them, so that they can focus on their goal. Or reverting to basketball: a center will need a point guard to get the ball up the floor and feed him. Why? Because he is better at it and it is his job.

 

Early in my coaching career I missed out on some of these points, but later on, when I managed teams to live by these standards, teams more often than not succeeded. The definition of success is a totally different story and that is when talent and skill get back into the game. But with the above mentioned ideas, I feel that a team can be more than the sum of its parts (that idiom had to come somewhere…).

So who is to establish these five points? Well, in my opinion it should be the one in charge of the team, i.e. team/project manager, or the one whose role it is to establish these habits, i.e. scrum master (and no, I don’t want to go into the generalist vs. specialist discussion on scrum teams here). Whoever does so, it is most important that he is good at communicating as sometimes a bit of a salesman attitude is required, especially when there is no agreement on goals.