Building Team Dynamics in Software Engineering Team

When it comes to my experience in building software, I often find myself in a team that is dominated with men. There was a time that I was the only woman too. It was not an surprising situation since according to U. S. Equal Employment Opportunity Commission's report (you can see it here), compared to overall private industry that consists of 48 percent of women, technology sector only employs 36% of its workforce with women. I don't live in US, but I guess the situation in Indonesia is very similar. I do realize that this topic is not mentioned very often since people here only care about skills and qualifications. So, as long you could contribute to the team, you will be fine (there is no preference over one gender).

I am very lucky that my team in software engineering course is an all-female team which I think it will be a very rare experience😅. I won't write about what's the difference since it is very subjective. What I am going to discuss is our experience in building team dynamics, which you can apply in your team as well!

Group Dynamics Theory

Although team dynamics concept seems intuitive, apparently there are many models that tries to represent stages of group dynamics. One of them is Tuckman’s Stages of Group Development that is proposed by Bruce Tuckman back in 1965. According to Tuckman, there are 5 stages that a team will experience: forming, storming, norming, and performing.

1. Forming

This initial stage is when the team has just been formed and each member may not be familiar with others. At this stage, everyone tries to get know each other. Since the goal is not clear yet and no one knows what they should do that time, it is better if there is someone that decides on what they should do.

In my case, I know all of my teammates but there are some that I am not close with (haven't got chance to be in the same group before). Our first discussion is when we want to vote for an app idea that we are going to choose. Of course, we were very confused on which one that we should choose. I tried to list options that I feel great for us and do listing of each app's plus and minus. From there, members got clear idea on which one was better and finally decided with one idea. Since the app idea was decided with first come first serve, we encouraged and made sure the one who will vote to wake up early and vote faster😂. Apparently, this small thing matters in building team dynamics.

From there, we got first task, which was to make a pitch presentation and high fidelity prototype. Since we have someone who is very great at designing, she was naturally be the one who delegated tasks to us. For people like me who is very clueless on design, having a direction is very important.

2. Storming

Storming is identical with bad weather, which you can guess, it means the team will experience conflict. It doesn't mean a member have a fight with someone else in the team. It can be in a situation where members have conflicted ideas. It can be also in a situation where the team hasn't reach agreement yet.

Since our team likes peaceful situation, the storming stage is not applicable to us😂. If there is a time that I consider it as the storming stage, it would be the early time when we learned about React. Since most of us are not familiar with React, it really took time, sweat, and tears to learn React. We spent overnight and didn't sleep only to implement our homepage, register, and login page with tests (don't copy our bad habit!). It was very tiring but from the experience itself, I became aware what each member's strength and weakness.

Our storming stage happened too after we finished our first sprint. We found out that the tasks were not distributed equally. There are members that had hard tasks and the rest got an easy task. Although I don't know if there are members that thought it is not fair, we felt it was better if everyone got equal easy and hard tasks so we got hard skill experience from it.

3. Norming

This stage is when the team has resolved conflict and each member know their roles. The team will work independently but keep checking if their work is effective.

In our experience, this was after the time when we already familiar with React and found issue in distributing tasks. Then, we distributed our task based on our previous task (for example, if someone already got hard task in previous sprint, she will get assigned to an easier task, vice versa). Since we were already familiar with React, after we get a task, we already know on what we will make, but we also confirm with each other if our step is correct. For example, someone will give explanation about how she will implement a component and will ask confirmation if it is correct or not.

4. Performing

This stage is when the team already familiar with the workflow and the team members will be more independent. The team members don't need to be instructed and will only ask if there is a problem.

In our situation, this stage happened in third sprint where we rarely conduct sync meeting to do code together. Since we become good at the system, we rarely ask for a lot of help. We only discuss progress and opinions.

Tips in Building Team Dynamics

1. Motivate Team and Set Focus to One Goal

Since we use Agile and our sprint lasts for 2 weeks, there will be time that we are very tired and end up not progressing at all, which is very okay and understandable. What we did to motivate was saying like "Let's finish it, this sprint will end in Monday!". By setting our goal to make sure we deploy it before sprint review in Monday, we will become less procrastinated and making sure our time is not wasted.

2. Always be ready to help if there is a problem

During our early time, most of us haven't worked with React. Since I was the one who already learn it, I always be ready if there is a question in our group chat. Later on, when someone asks for confirmation, each of us always ready to answer quickly so the confusion is resolved quickly.

3. Set tIme to talk heart to heart

Sprint retrospective is a good time where we could evaluate and talk heart to heart. In other sync meeting, we were focused on coding so we couldn't talk about it. We could identity problems like not distributing tasks fairly because we talk it on our sprint retrospective.

4. Give praise and appreciate the result

Make sure giving praise after the team finished the hard work. Giving praise actually matters to people who are not confident with their work. It also make sure that the team do a great job.

We also got an appreciation based on our hard work, which was Product of the Sprint. We felt very happy and become more motivated after we got an appreciation. Appreciation means that our hard work paid off.

Although our team is an all-female team and there is a time that we are getting asked like "Oh, your team is all-female?", it doesn't mean we are less qualified than others. We could prove that our support to each other works and we could achieve our target. Some of our team members are not confident in our early time. But, by having great support from others, we could be encouraged to be very confident and do great work!