COVID-19. Need I say more? It’s totally changed how people work and will affect how workplaces operate for years to come. This article discusses how we, the Supergen team, worked together despite never meeting in person and being spread across different timezones.
In order to function well as a team, all members should get along with each other, understand the state of the project, and feel able to have their say in any choices made. The root of all of this is good communication. This is less of a challenge in person; it’s easy to ask the person next to you how their work is going or request help with your own. You get used to being around and talking to colleagues, so bringing up issues or suggesting changes becomes easy. When you’re all working remotely though, good communication becomes more difficult. Sitting alone coding away for hours a day can be very isolating and makes it difficult to reach out to people, since you aren’t able to approach them as you could if you were in the same room.
This article discusses how we worked as a team despite being in the middle of a global pandemic and spread out across countries. I’ll talk about how we implemented agile and other practices, and the tools we used to do so.
The tools we used
To contextualise the agile practices we employed throughout the project, I’ll first talk about about the tools we used over the course of the summer.
Day-to-day communication
For day-to-day communication, we started off using Slack. I set up a Discord server as well, with channels for each team in the company to use, since Discord offers audio and video calls as well as screen sharing. We soon found ourselves split between Slack and Discord, since we’d have our team meetings on Discord, but more formal communications were on Slack. Eventually we decided to move things over to Discord completely, so everything would be in one place. We added bots which reported information from GitLab and Trello to relevant channels, so Discord became our central hub for communications. Any decisions made that were significant enough to be logged would be noted on a Trello card, as opposed to Slack as they were before. Having a mix of professional and casual interactions on Discord allowed us to bond better and feel more like a cohesive team.
We used Zoom for meetings with the client, since it was their preferred method of communication. We considered using it for our own meetings too, but Discord’s ease of use was unbeatable; you can join a voice channel at any time, set permissions for users, have any number of text and voice channels, etc. which Zoom doesn’t allow you to do easily.
Project organisation
We used Trello to map the project out. Our board had various columns, allowing us to see each task’s current status:
- Backlog – tasks which need to be completed at some point in the future
- This Release – tasks we intend to complete and have integrated for the next release of the app
- This Iteration – tasks that we intend to work on during this (one-week) iteration
- Doing – tasks we’re working on right now
- Internal Review – tasks which have been completed by someone and are awaiting review from other team members before integration
- Client Review – tasks which have been approved by the team and need to be looked at by the client
- Done Done – tasks which have been signed off on by the client and team alike, and have been integrated into the app
We’d create cards, move them to relevant columns and tag them to ensure the Trello board accurately reflected and logged the state of the project. This kept everything organised and meant that we effectively had a dashboard from which we could see how the project as a whole was going. If used properly, Trello is an excellent tool for project management.
We used GitLab to host code, raise issues and perform reviews. It’s a great tool for these purposes and will be discussed more later on in this article.
The practices we employed
As team lead, I had to make sure everyone felt engaged and involved from the beginning. With guidance from Suzanne, we set up a team process that facilitated this and worked for everyone. Several practices, both agile and non-agile, were employed to ensure everyone felt in the loop at all times and keep the project running smoothly:
- Meetings:
- Daily Standups
- Iteration Planning meetings
- Retrospectives
- A no blame, positive reinforcement culture
- Whole team responsibility
- Core hours
- Git and code reviews
Daily Standups
Standups are short daily meetings (usually around 2 minutes per team member) during which you discuss what you’ve worked on since the previous standup, what you’re going to work on until the next one, and anything that is blocking your progress. Any issues raised during the standup are noted and discussed afterwards.
We had our standups in the mornings, as a focal point for the team and to get everyone in the working mindset at the start of each day. The standups helped us feel like a team rather than four separate units and afforded us a better view of the project as a whole, as we’d see parts of it that we haven’t personally worked on grow day by day. It also provided some much needed conversation between team members, which helped us bond.
Iteration Planning meetings
During these meetings, the team plans out what it’s going to do during the iteration (which was a week long, in our case). We had these meetings on Mondays, replacing our standup but starting an hour later, because nobody likes having a meeting early on Monday morning!
Our process involved moving all cards that aren’t Done back to This Release and from there assessing where they should go. Some tasks would be put back in the Backlog and some would move to This Iteration as part of that week’s work, while others would remain in This Release, to be picked up during a future iteration.
From there, we’d go through the tasks for this iteration and assign them to team members, ensuring that everyone’s working on something they want to do and nobody has too much or too little work. This process took a while to refine, because at first we didn’t know everyone’s working pace.
Retrospectives
Retrospectives were our time to reflect as each iteration came to a close, every Friday afternoon. We used Miro, a collaborative whiteboard application, so we could all contribute in real time. Here, we’d create notes in four different categories:
- What went well this iteration
- What could be even better in the future
- Blockers that are currently hampering progress
- Changes we will implement in future iterations
Once we were done creating notes, we’d discuss each category. This allowed us to recognise and celebrate the things we’d done right, discuss and tackle issues that were preventing us from moving forwards, and plan improvements to our process. This constant adjustment and refinement of how we worked meant we were always improving, and by the end of the summer we were a fully cohesive unit.
For example, during the first half of the summer we struggled with setting workloads – sometimes people would run out of tasks or have too many to handle in one iteration. Week by week we got better at this, eventually being able to accurately divide the workload among team members so we all had just the right amount of work each iteration.
The Miro board logged the things we liked or decided to change and why we felt change was needed, so we could look back on the decisions we’d made.
A no blame, positive reinforcement culture
The culture of a team should healthily promote good work by keeping everyone in the team happy, motivated and productive. Throughout the project, any issues that cropped up were seen as shortcomings of the team as a whole rather than a particular individual. This is absolutely vital to team productivity. If someone feels they’ve been singled out or their hard work hasn’t been appreciated, it could cause them to lose motivation or doubt their ability to do the job, which would make that person miserable and unproductive. Thankfully, we all got along so well as a team that there was no point at which I had to explicitly enforce the no blame policy.
This, paired with constant positive reinforcement, helped us to work better as a team. Recognition and praise for things that went well was vital and motivated us all to keep doing those things.
Whole team responsibility
The positive culture of the team was promoted by our use of whole team responsibility – if something went wrong or needed work, it wasn’t just one person’s job to do it. Everyone was responsible for everything, so tasks wouldn’t be left incomplete because one person was busy while other team members were available. For example, at one point our BA, Jang, took a few days off from working. During that period, Miranda stepped up and took over his responsibilities, and handed them back once he was back without issues. We were constantly taking a look at each other’s work and handing tasks between members. This ensured that the main tasks would always get done, even if their assignees were struggling with them or busy with other things.
Core hours
It isn’t strictly an agile practice to have core working hours, but over the summer we found it really helped our communication. These are hours during which every member of the team must work on the project and be available to contact. Since three of us were in BST but one of us was in BST+1, it was important that our working hours were fair. Nobody should have to work inconvenient hours because of the country they live in, ideally. Our core hours were 10am-12pm and 1pm-3pm (BST); two hours in the morning and two in the afternoon, during which we were all online. This meant we could communicate with ease, knowing when people are available, but could also work flexibly. Those four hours were mandatory, but the other three we were paid to work each day could be done at any time. This flexibility is very important when working from home, because it lets you schedule your work to suit both yourself and the team.
Git and code reviews
Code reviews were vital to ensuring our codebase was the best it could be. We mostly followed GitFlow, using a dev branch with feature, fix and test branches coming off of it. These smaller branches would be merged into dev once work on them ceased, and dev would be merged into master, adding finalised features which were ready for deployment.
We did our code reviews on GitLab, since it allows you to comment on specific lines of code, attach images and comment in (and resolve) separate threads. This kept all our reviews in one place, under each merge request. It also allowed us to link to issues in the issue tracker if a merge request fixed a bug.
Our process was tweaked and refined constantly over the course of the summer. For example Amish’s merge requests, which were incredibly descriptive and covered all necessary information perfectly, were far more useful than the rest of the team’s MRs at the beginning of the summer. We all took a leaf out of his book and improved our own requests, until we were all writing much better MRs. This made reviewing code much easier too, since we had a description of what the code was intended to do.
Summary
To summarise, our team process implemented various principles. Along with the tools we used to put them into practice, they helped us work well as a team despite being remote. We got along incredibly well and were able to hand tasks between team members with ease. At the beginning of the summer Suzanne Embury, our Academic Lead, ran meetings and oversaw our process. I soon took over its management and towards the end of the project the rest of the team took turns leading meetings too. For me, this summer has served as great hands on experience in managing a project and leading a team (even if the team was amazing enough to not require much leadership!). I am convinced that agile is the way to go for project management and believe it will only become more important in the future, as companies around the world continue to make their work remote. I hope the rest of the team found this experience with agile as insightful as I did!
Huge thanks to Amish, Jang, Miranda and of course Suzanne for a summer I’ll remember and draw inspiration from for years to come!