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!

How to talk about technical topics to other developers?

The most important soft skill for developers is the clear and effective communication. There are several situation when this skill is really needed. It is simply because the most of the projects is done is a kind of team work, so you need to simple talk to the other team members. One usual topic is to discuss about technical topics. Unfortunately a lot of developers are missing such skills and that’s why team work is becoming non effective in several cases. Let’s see how should these discussions to be done.

Why to talk about technical topics?

I often meet developers who think that it is simple a waste of time to talk about technical topics, just let them work and they will implement everything. This way of thinking is really not fitting to the modern ways of software development. First of all it is totally against teamwork. Additionally at a company usually the developers have different levels of knowledge in different topics, so really often knowledge transport is needed: you need to ask more experience colleagues for better solutions and you need to teach the less experienced ones to let them work more effectively.

The other point is that it is not always trivial to find the best technical solution for a problem. This topic is totally not black and white. For most of the solutions you can not tell that this is better, than the other, because it is not a scalar topic. Most of the cases you can tell for example, that this solution is better in runtime, than the other, but the other solution is using less memory. In our current situations we don’t have issues with the runtime, but we have a lack of memory, so let’s choose the second solution.

To be able to talk on this level you need multiple alternative solutions with all pro and cons. And to collect these ideas usually you need to talk about them, to talk a lot.

There’s also a point at quality: to improve software quality reviews are part of the daily work and at reviews you need be able to describe in an effective way why do you think that your solution is good or why do you think that the used solution is not good.

That means communication about technical topics is part of your daily work, if you don’t want to waste so much time you should learn how to do it in an effective way.

How to coach colleagues?

Typical situation that there’s someone at the company who has really good experience with a specific topic and he needs to support the other colleagues working with this topic.

In this case you need to do technical coaching to the others to support them to finish their work. It is also important for you that they are able to finish their work and it is also important that they are understanding the how and the why and they are not asking the same questions in two weeks again.

In this situation first try to understand what if the level of knowledge of the others. You can easily do it by some nice questions: “Do you know how this and this is working?”. But important: don’t try to make them feel that they are stupid just because they have a lack of knowledge. After that try to clarify the theory with all the reasons what are you doing and why. Once it is done do an example or a small part of work together, but don’t finish the work together, let them try it on their own, but stay always open for questions.

For coaching pair programming is also a good approach. Sit together in front of the computer. First you should do it and clarify each step. After a while let's change but still tell what should be done. With time you need to talk less and your partner needs to talk more.

How to ask colleagues for support?

The next situation is you are blocked in work and you need support from someone more experienced in the topic. First of all don’t ask as soon as you’re facing with difficulties. First try to understand what is exactly the problem and why is it not working. Also search for that in google and check for possible solutions online. If you can not find a working solution within a certain time don’t waste your time anymore, ask for search. Before asking for search try to summary what is really you problem and your question. Make sure if the chosen colleagues has some free minutes and he can listen to your problem. When you are asking don’t waste in details, because if you are giving a lot of unnecessary information it will be more difficult to understand your problem. But also take care about enough details. I got questions really often in a similar way, like: “I would like to push a shared_ptr as parameter and it is not working”. Ok, come on, why are you pushing the shared_ptr? Shared_ptr of which type? Is is const? What does it mean, it is not working? But the best if you are showing simple your code and clarifying what is your goal. If your code is far too complicated try to create a minimal example where the issue appears by removing irrelevant code part. You also need to understand that even if the other one is expert of the topic, he needs to understand your goal and problem first and it is not so easy.

How to ensure colleagues about your idea?

Also really typical if you have an idea about how to do something. It is always good to discuss about that with your teammates before implementation, since it is possible that even if you think it is a good idea in practice it has some disadvantages which are still not clear for you. It is also important if the other have other solutions listen to them, let’s try to understand their purpose and let’s try to understand what are its advantages over your solution. Then try to think what are the possible disadvantages and point out them. If you are talking about your idea first describe what is the problem to be solved and what are its main challenges. If it’s clear for everyone you should tell your idea step by step. At the end you can point out why do you think that it is a good solution, but you should also mention if you see some disadvantages. It is also good if you are talking about alternative solutions and at the end you are telling which one seems to be the best for you. If the others are criticizing your solution try to understand their reasons and ask them for suggestions. If your idea is to complicated it is good to create some diagrams of minimum working code example.

How to give a feedback about a technical solution?

If you are on the other side and one of your colleague is talking you about his idea it is also not always easy to answer in the right way. If you agree with the solution then it is easy, underwise it can be difficult.

Even if you think that the idea is super stupid you need to trust your colleague and his idea. You need to first understand his idea fully and also the reason why he is suggesting it. If you still think it is not the right way just point out why you are feeling uncomfortable with the solution (what are your fears) and try to give some solutions how these issues could be resolved. Never forget to mention the parts of the solution which you like. For example:

“This solution would really be well-structured and clear, but I think there are some corner cases when it wouldn’t work correctly. But if you are changing this part to that it would do what is required.” Something like this.

Summary

Communication is never easy, especially between developers and about technical topics. Try to always use the rules of assertive communication, give reasons and trust the others and you will see, it will work and it can really burst your career.

From individual work to team work

Since the projects are constantly growing and the time pressure is getting higher and higher in the software business to walk alone on a project is not an option in most of the cases anymore. On most of the projects big teams are working from some people up to multi-thousand. But how are these big projects organised? Are the people working in a team or just individually . Are they really work in a team? Is it good if they are really work in a team?

The classical way of working

At most of the projects a projects is splitted between the different subteams based on some well-specified area: components, knowledge area, activity (architecture, testing etc.) or functionality. So each subteam has its clear job with well-specified inputs and outputs and they need to sync up sometimes with each other, but they are basically working independently.

How is the work organised inside a subteam? At all my previous projects the situation was the same: the wok was splitted up to smaller tasks and each task was assigned to a team member. That means each team member had its own task, own responsibility. Everyone was just working on his own tasks. The only interaction happened between the team members at the daily status meetings, at code reviews and if someone asked from help. But normally the team members were not technically deep in what the others are doing. It resulted the following situation: one hand you could working concentrated on your tasks, which was effective as far as you had all the necessary knowledge. If you stuck it took a long time to get help, because the others were also busy with their tasks and they needed time to understand what you are doing. Another difficult situation was when some became sick. Quite often no one else could finish his job without a really huge overhead. So it was always almost causing problems. It was also challenging when someone left the project. Most of the cases he had project-specific knowledge which the others didn’t have, so a knowledge transfer needed to be done. It was always difficult to work with junior colleagues, because they often stucked and lost days with trying to figure out their own solution.

On the other hand it was really comfortable that after getting familiar with the project you were able to work really independently, it was easy to work for example from home office due to the lack of interactions.

To escalate the problems the management was tracking our performance on a personal basis. That means if you wanted to reach a better number next to your name in the performance report you really needed to concentrate on your tasks and avoid wasting time with other issues. It was totally not productive.

The way of real team work

Now I changed to a new company and I’m working on another project. Here the way of working is much different. It is real teamwork here. The tasks are assigned to the team and the to a specific team member. Usually we are working on less task than the number of team members. The is no dedicated person the work on the specific tasks. It is really typical the 2-3 team members are working on the same task by doing pair or mob programming. So we are all sitting in front of one computer and working. It reminds me on my childhood as we were working with computer games with my friends, but we had only one computer. We are also changing tasks between team members frequently. It can be that one day you are working with one guy on one task and on the next day with other guys on another task. This structure is basically solving all the problems I mentioned before: the whole team is aware of the technical content of each topic and there is always multiple people who are deep in a specific topic. So that a sickness, a holiday or a change in the team does not mean a big problem. The junior colleagues can also work together with more experienced team members and they are learning really fast in this way.

On the other hand we often have the feeling that it is not effective at all what we are doing: three of us just sitting in front of one computer and talking about one easy class….hmm.

It is also mentally challenging: instead of listening to music and concentrate on the task, you need the follow and participate discussions all the time, listen to others opinion and formulate yours. This kind of close cooperation is also causing several conflicts between the team members. All things considered it is not so easy to work in such a structure, but I can see also several advantages.

In such a working structure you need to be able to communicate properly, describe your ideas and issues properly and to be very patient and flexible.

I have not the feeling that the best working model would be a hybrid model between strong teamwork and individual work. If you have experience with working in such a working model it would be nice if you could share them.