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.
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.
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.
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.
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.
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.
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.
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.