Teamwork Makes the Dream Work

…is what people usually say.

Over the course of two sprints, we have worked on our project, and I think it’s safe to say that we found a somewhat comfortable pace. Throughout those two sprints, some things have happened, some good, some bad, but most of all, it serves as a learning lesson for us to improve our teamwork.

In this article, I will share things that have happened during our sprints and try to advise how you should improve your teamwork.

The workflow

For starters, we divide our workload in the sprint planning phase, where we divide PBIs into smaller tasks and then assign a person or two to work on that task.

This is our taskboard for our third sprint.

From there, every time we are done with our tasks, we submit a merge request to merge all of our work into one. That is the generalization of our workflow.

How we work

While we have our own tasks to do, we usually meet in a group call so we can immediately ask for help or suggestion. We use Discord for our group calls, as we have a preexisting Discord server that we normally use for talking and doing academic stuff (homework, etc.). If there are no people in the group call, usually we ask if anyone is free in our LINE group.

When someone submitted a merge request, we usually announced it in our LINE group so that people can immediately review it. This helps to speed our progress, as not announcing it can lead to the request being unchecked.

Building the team

As we were allowed to create our own group, it’s natural that most, if not all people decided to make the team with their friends, and we are no exception. We are already familiar with each other since the first semester, and even then this is not the first time we are in a group together for a course, as all of us were in the same group for our Game Development course.

Our group for Game Development, plus another one of our friends.

Besides grouping for projects and academic-related works, we usually join the group call when we’re free to do other stuff. We discuss our hobbies together and sometimes play games together. This happens sporadically, and it can happen either after class or from 8 PM until after midnight.

We had a game of 4-player chess at 1 AM.

Problems and how we handle them

Disagreements and bickers

Of course, not everything is smooth sailing. As individuals, it’s bound to happen that we have disagreements, and sometimes discussions can get a bit heated. But these usually are resolved after a while, and things continue to move on as usual.

One member down, part 1

In our first sprint, one of our member’s laptop’s charger exploded, leading to him being unable to continue his work until his laptop is fixed. Luckily, we immediately decided to do pair programming, with me typing and committing, while Egi, the person with the recently-exploded-laptop-charger telling me what to do.

That’s another censored word.

I also changed my git account to his so the commits are written as his commits, rather than mine. This also means he can use these commits for his own review.

Database

The choice of what database we should use for our project has been discussed since before the first sprint, but in the end, we decided on using SQLite, which is the default database for Django, the framework we are using. Some of us weren’t too pleased with this decision, as we already learned how to use PSQL back in our Databases course, and overall PSQL is one of the better databases out there.

After few troubles regarding our database before our first sprint review, after that, we decided to migrate to PSQL. On paper, this should be a good move, but the reality isn’t always what we expected.

Taken before disaster.

For reasons unknown to us, one of our members can’t run PSQL on his laptop, therefore making him unable to test properly, or do things that require database access. And considering our project is an inventory management app, we will need to access the database many times. Due to this problem, we ended up reverting back to SQLite, therefore wasting some time on our work.

One member down, part 2

On the 22nd of April, I was tested positive for COVID-19.

This probably is the culmination of me feeling sick for like 6 days before testing, in which I didn’t continue on the work I was assigned with. The test result came around 3 or 4 days before our sprint review, so the rest of the team had to adapt pretty quickly.

These tasks were supposed to be worked on by me and another member but in the end, he took over the rest of the tasks.
I also have to skip group meetings and UAT as I had to rest completely for a few days.

Thankfully, the sprint review ended up pretty well and the features presented seem to satisfy our client, so I guess everything worked out alright in the end. Speaking of sprint review…

What if you want to present but PLN said no

There were supposed to be 2 presenters for our sprint review, Rocky and Egi. 20 minutes in it seems like everyone is ready, but after everyone joined the Zoom meeting for the sprint review, Egi went missing.

attempts were made.

Turns out, his lights went out right before the sprint review, and somehow his mobile data were apparently empty as well, therefore he was unable to be reached. So poor Rocky had to adapt to presenting by himself, and he put a good effort in doing so, although he stumbled a bit in parts where Egi was supposed to present.

Lessons to be learned

Overall, just like any other project there are bound to be problems, some are recurring, some are one-offs that should not happen again during the working period. But from these accidents, I can take some points in order to improve our team, and hopefully your team as well.

Communication is key

It is very important to tell your teammates what you’re doing, what’s your situation, and if there are troubles that you’re facing. Fast communication means that your team can immediately look for other options and plans, and of course, letting your team in the dark about your situations is never okay. It is also important to communicate when making decisions that will impact the team in some capacity, and making sure everyone is alright and can continue with the changes will help to keep the workflow.

Backup plans

As I’ve written above, you’ll never know when disaster strikes. Therefore, it is advised that you make backup plans for your team, such as who’s going to take over if someone is unable to work, and other scenarios that you can think of. Just like testing your code, preparing for any outcome can be a bit time-consuming, but will do your work no harm.

Know your friends, know your teammates

This is quite important to do, especially if you are on a randomized team with people that you don't really know of. Understanding each person on your team can help you evading negative thinking, and can also help you create decisions much faster.

If you’re in a group with your friends, it is also important that you do some team-building exercises or just have fun doing something, as work situations can be quite tense, and if it carries over to outside your work, it can lead to altercations and even worse, ending a friendship.

I hope this article could give a little bit of insight into how our team works. Hopefully, this can give you some ideas for you and your team in order to work better.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store