How to do real teamwork in a software team

Introduction

Earlier programmers were lonely wolves, working alone on their ideas and projects. In the meanwhile the whole business became much faster, one of the biggest challenges is to deliver solutions in time. Most projects have a strict due date and the technology is changing so frequently, that you have to be really fast to do some meaningful innovation (and to be the first). Lonely wolves have no chance in such an environment. You can not do breakthroughs alone. The only possible way to catch up with the time pressure is to work in teams.

Nowadays most of the programmers are working in teams. This makes a lot of challenges, since next to good technical skills, good soft skills are also required.

Do the developers do real teamwork nowadays? Could they be more efficient by working closer to each other?

Assignment of tasks

At most of the companies I used to work the tasks were assigned to dedicated developers. This assignment was usually done either by the project manager or by the most experienced developer (kind of technical lead). So every developer got their tasks and then they started to work on them.

There was a bunch of people, called team, and each of them was working on different tasks individually. Sometimes they had sync meetings where they mentioned some words about their task. But of course they couldn’t give a good overview on that for the others.

There was some team spirit of course: we went out together for lunch everyday and we did a lot of team building event which gave the feeling that we are really parts of a team and nevertheless we were working on the same project.

Of course if someone got stuck the others tried to help, but since they were not deeply in the topic of other tasks it usually took ages for them to understand the issue and even more to find a solution. So even if it was called teamwork, it was rather the work of a bunch of individuals who supported themselves sometimes.

It the root of the behavior was the assignment of the tasks. Each developer had their own tasks. They were responsible for that task. If the task was not done in time or with the right quality it was their responsibility. And if the task of their colleagues was not done in time, that was the responsibility of the colleague.

Just imagine the situation: you are a bit late with your task and your colleague asks you for support. You realize that the support would take a bit longer, which means a high risk on your task. Of course you won’t help, You will just give some quick guess how to fix the issue and that’s it. But at the end your task will be done, but the task of your colleague may be blocked right at the beginning, it will be very far from being done. So on the level of the project it is a pretty clearly worse situation that being a bit late on one task.

Later I changed to another company and other project where the mindset is much different. I experienced a totally different way of teamwork, which I found much more efficient, even if it has some cons. That’s what I will introduce now.

The main idea here is that the tasks are not assigned to individuals, but to the whole team of 8-9 developers. The team has a certain amount of tasks to be done within a dedicated time frame. Everyone can overtake any kind of task, so there’s no separation between the team members based on areas. And at the end the whole team is responsible for all of the tasks to be done on time with the right quality.

So that if one task if blocked, it’s important for all team members to find a solution as fast as possible.

Later on, of course the team can split the tasks to subtasks and assign these subtasks to individual, but still there’s a common goal to finish everything in time.

This attitude is also good in case of unplanned sickness and holidays: it is not blocking the whole work on the tasks for weeks, the team mates can overtake it, since the goal is still to finish everything.

This way of cooperation makes the workload more balanced: there are no people without tasks and people with too much to do. Once you have nothing to do, you take a look where you can help. If you are waiting for another part of the code, you won’t sit workless, you will help the one working on that part.

This attitude makes the whole development faster and more relaxed.

Knowledge transfer

To be able to work in such a way it is a must to be on the same knowledge level for the same team as much as possible. This method will never work if there is one guy who knows everything and the others have no clue about the task and the technical background.

Of course it’s rarely the case that the whole team has around the same knowledge. To be able to get closer to this point you should do a lot of knowledge transfer. The one who has better experience with one or the other topic should spread this knowledge within the team.

The very first step if to offer technical training for the team members in different topics to fill the big gaps. It is also needed to provide some time for the developers during their working hours to learn from the Internet, from books or from online trainings.

Additionally there should be some knowledge transfer more related to the tasks.

The first way to do it is to have regular knowledge transfer meetings where team members can present their challenges and solutions during their last tasks.

Next to that it is a good practice if the team members always take a look at the code of each other. But mainly the most important point: if you are blocked, if you don’t understand something: ask, ask and ask the others. Don’t let you have question marks in your head.

Other than this there are two more radical ways of knowledge transfer.

The first one called pair programming: a lot of developers don’t like it, they think that it is a waste of time, they feel uncomfortable to talk to others all day long. But it is really helping the flow of knowledge within the team. At the beginning I was also sceptical. But later on I realized its power.

It means two of you are sitting at the same computer and working on the same task. It is good to set up the pairs in a way, that one who has better experience with the topic and one who have less knowledge. So that the one with less knowledge will learn pretty fast. The idea is that one member of the pair is typing and the other one it telling what to do. To be efficient you should change frequently the roles.

On the other hand to do pair programming is exhausting. My suggestion is: don’t do it all the time, just if it’s necessary. You can start to solve the task in a pair and once it is clear for both parties how to resolve the task you can split it up into parts and continue to work separately.

The second way of knowledge transfer is a bit more radical. It is called mob-programming. That means a team of developers is working on the same task in front of the same computer. For that you need a huge display. There’s always a leader of the mob session. The leader of the mob session if the one who is typing on the keyboard. The leader should be changed after twenty minutes. This is a really efficient way to bring the whole team on the same level in one topic.

But the way how you are doing the knowledge transfer is always up to the team and the topic. One goal is to share the knowledge, the other one is feeling yourself comfortable. You have to find a way which satisfies both the points.

How is well-working team?

I collected some points, if they are satisfied, your team is doing a proper team work:

• Every team member is aware of the common goals
• Every team member knows what are the others working for and what is their status
• Every team member is able to overtake any of the tasks
• Every team member knows how last technical challenges has been resolved
• If a team member is sick or has a vacation that has no big effect on the team performance
• If one team member is leaving the team that has no big effect on the team performance
• If one team member is leaving the team no additional knowledge transfer is needed
• If a new team member joins the team, that doesn’t have a big effect on the team performance.
• The decisions are made together
• The responsibility is shared within the team
• At any of the meeting any team members can take part (no need for one dedicated team member to join)
• The team members enjoy working in the team

Evaluation and feedback loop

In case of classical team setups developers are evaluated based on their individual performance. In optimal case they also get regular feedback about their attitude and behavior.

For developers it is really important to have some realistic goals and to get a regular feedback if they are doing things in the right direction. In classical teams this feedback comes usually from the team manager, project manager or from the technical leader.

In case of close teamwork we have to make a difference between the two levels of feedback: the team level feedback and the individual level of feedback.

The team level of feedback should come from someone who is not part of the team: team manager, project manager or customer. This should be reflected on the common goals of the team, so that the team can find the points to be developed.

The individual level of feedback has two sources: the first one is nothing else, but the team. The team should have a way where team members can give feedback to each other. It can be feedback for the whole team, like “we should plan the tasks more properly” or “we should do more pair programming”. But it can also be on a personal level if there are issues with a team member. The form of that can be either a feedback meeting, where team members can tell their opinion in a structured way. Or it can also be done by filling out an anonymous questionnaire.

The other source of feedback should be still the management, who can help to find a direction for personal development, like improving dedicated skills, taking part in trainings etc. I think this part is still really necessary, since as human beings we need such a level of advice and feedback.

Biggest challenges of close teamwork

This way of working works properly in an ideal world. Fortunately this world do exist. But there are several points to be fulfilled: a customer agreeing with this working mode, a management supporting this working mode and team members who are agreeing with this working mode.

Furthermore it is necessary that all the team members have the right soft skills of communication and conflict management as well as that they can work well together. And this is the biggest challenge. A lot of software developers don’t like to communicate, don’t like the team work and some of them even doesn’t have the right skills to do it. For this kind of work team members need outstanding communication skills or at least average ones. That’s why it is a big challenge to set up such a team.

It is also important that the team members should have similar technical knowledge. It is really difficult to involve a total beginner junior into such a teamwork unless slowing done the team too much. This also means that the costs of developers with the right technical and soft skills is pretty high.

From a personal perspective I think the biggest challenge is to find a way of working which is fine for all team members. Next to that it is exhausting to cooperate all day long, but with time you use to have it. It also takes some time to feel comfortable with the shared responsibility.

Summary

To do real teamwork in a software development team has a lot of challenges, but even more benefits. Everyone should try it!