Over the last 12 years, I’ve had the pleasure of working in a mixture of in-office, remote and hybrid (a mix of in-office and remote) teams. During that time I’ve observed many things that have hindered a team’s ability to communicate and collaborate effectively. In this blog post, I dive into some of the issues I’ve seen and possible ways to overcome them.
When COVID-19 struck the world, it significantly altered the landscape of how some software engineering teams work in several different ways.
One of the most noticeable changes is the widespread adoption of remote work. Teams quickly transitioned to remote setups where feasible. Whilst this shift provided flexibility it has also made communication and collaboration at times a little more challenging for many.
Of course, poor communication, and collaboration have long been an issue for software teams working in an office environment way before the recent acceptance of remote working. With COVID-19 and teams being forced to suddenly switch to a fully remote or a hybrid approach this has only amplified many of these existing problems.
When working as part of a remote team, teams need to use tools for virtual meetings, product management etc. However, many of the issues I’ve observed within remote teams have been around how these tools are used. Very often many of these tools are used in a particular way in an attempt to make up for a lack of communication or collaboration within a team.
Slack (or any other chat tool)
When working in an office, if you need to ask a work related question it can often be simple to get the answers you need. Of course, it depends on the question you have and the person’s location but very often if the person is in the same office you can see if they look busy, and if not go over to them and talk to them. Working remotely can be a bit more of a challenge.
Direct messaging somebody and not asking a question
Whilst directly messaging somebody might seem to be the easiest thing for you, this can often be the most disruptive thing for them. The other person is probably in the middle of something and your message is forcing them to stop what they are doing and context switch.
If you feel you need to message somebody directly, ensure you ask your question and keep things to the point. It’s fine to post pleasantries but don’t just do that in a message without your actual question, disturbing somebody who is probably busy and then keeping them waiting.
That’s not to say you can’t just have a chit-chat, of course you can but if you are reaching out to somebody for help or with a question be mindful.
This site sums this up quite well - No hello.
Direct messaging - keeping things in the public/shared channels by default
Before I go on, I love to talk to people and I like it when people say hello. However, due to the nature of my existing role, a large part of my role is dedicated to supporting teams and I can often get many support requests at one time making things a little chaotic.
Before messaging somebody with a work-related question, search Slack (or whatever chat tool you use). A large part of the support requests I get are for help for things that probably could have been found by the person asking the question. It’s always worth searching to see if your question has been asked before. If not, the question you are messaging somebody directly about will also be hidden from others in the future. Keeping discussions in shared/public channels will help others to be able to help themselves.
Some places I’ve worked also have dedicated channels set up to ask particular questions i.e. #testing, #front-end, #accessibility. This can make it easier to try and find the best audience for your message as well as to search for messages to assist you.
Long-running chat threads
People are often very busy doing their work and so feel that posting a quick question or quickly responding to one is the best way to do so. Often this might be the case but there have been more occasions than I can remember where I’ve seen threads of 30 or more messages, with individuals and teams being tagged halfway into conversations, crossed wires, missing context etc.
All of a sudden this quick question has disrupted many people. They’ve stopped what they are doing to read messages posted in the thread by others or stopped to respond themselves.
This isn’t a hard and fast rule but if a chat thread I’ve been tagged in starts to go on greater than 5-10 messages and I feel more messages might follow then I will ask if I can jump on a call/hangout session to discuss the query and try to get the resolution there and then.
It might not initially feel like the best way to spend your time. Still, in my experience it often saves me getting dragged into long-running threads enabling me to continue working and not getting distracted by further work related help requests throughout the day.
Virtual meetings
In a world where remote working is becoming more and more the norm, having a way to catch up virtually and see actual people is vital. No tool I’ve used has been perfect, they all have their pros and cons, but they do a job. They let us see and hear others in our teams to discuss what we are doing, any issues, general chit-chat etc.
Cameras
When speaking to individuals or teams I personally really like it when I can see the person that I’m speaking to. Very often I join calls where the other person or persons do not share their cameras. Of course, there will also be occasions where for whatever reason somebody cannot switch on their camera - they also might not have one. I also do not ask or insist on people turning on their cameras as they might not feel comfortable.
As a tester I observe how somebody responds, I look at their body language and facial expressions. Often people are afraid of asking ‘silly questions’ - there are no silly questions and people shouldn’t be afraid to ask, but often they resist. By seeing somebody’s face for example I can see when they might look unsure or confused. Seeing this can help me to try and reframe what I’m saying or try to break something down into a more understandable or agreeable thing. I also use this same technique if I’m in a meeting and I see somebody who looks like they don’t understand or agree with something but for whatever reason do not want to speak up. Quite often I will raise a hand and ask questions or raise concerns that I think others might be thinking based on their facial expressions or body language.
This isn’t always the case but one thing I’ve seen on many calls is where people have a camera off and aren’t engaging much in the conversation(s). If you do not have anything to add to a conversation/meeting, it’s worth raising this to the organiser/facilitator.
To be clear, I’m not accusing those who don’t contribute to a discussion or have their camera on during meetings are doing this but there have been many occasions on both teams I’ve been on and teams I’ve observed in an office where people turn up to a meeting and use it as an opportunity to do other things or have a break.
Stand-ups - going off-topic
I’ve been in many stand-ups over the last 12 years. Of course, there will be those who question why do stand-ups in the first place (that’s another debate) but if your team does hold a stand-up they should be very brief. They should be used as an opportunity to give any updates that might be valuable to the team and to raise any blockers or ask for any assistance if needed.
Sometimes during a stand-up, individuals might start to discuss a piece of work that is in progress in much more depth. The problem with this is there are probably other people on the call who have nothing to offer into the discussions.
Instead, it’s better during standup to flag things that require further discussions identifying the audience for the conversation and then having the chat either at the end of the stand-up or later on so others on the call can drop off and carry on with their work.
Individuals not engaged in the meeting
Over the last few years, I’ve noticed on many occasions individuals who are not engaged in the meeting and not paying any attention.
In an office environment, I would not expect any member of the team to be sitting down with their laptops, tapping away as the meeting takes place. In a remote team, this should be no different, and yet I’ve attended many meetings (stand-ups in particular) where you see lights flashing past people’s faces who are on the call, clearly browsing the internet or working.
The meetings should be there to help the team and be adding value. If they aren’t then it’s a great thing to flag with the team to see what you could do differently.
Stand-ups should be brief anyway not taking any more than 10-15 minutes for the meeting. It’s not healthy for the team to see somebody clearly isn’t paying attention or interested in what the rest of the team have to say. Again, depending on the meeting, if you have nothing to add maybe state this upfront and see if you need to attend the meeting in the first place.
Meeting agendas
I’ve lost count of the number of meetings I’ve been invited to and attended where there was no clear agenda. This has led to lots of people attending who didn’t have anything to add of value, the correct people not being invited, and discussions going off-topic.
Adding an agenda helps people to know what is going to be discussed, the correct audience for discussions and helps keep the discussions focused with a clear goal/goals to be achieved from the discussion.
It will depend on the type of meeting but where possible add an agenda.
Bored of meetings?
There will be those who like to do stand-ups, retrospectives, etc and over time things can get a little dull as teams follow the same formats. This can lead to situations like the above where people get distracted and start doing other things, not being engaged in conversations, being disruptive or unnecessarily awkward as they feel their time is being wasted as they have other things they are keen to do.
As a team, it’s for you to decide how to work, and what meetings add value, but sometimes changing the format can help keep things fresh. In a stand-up try to alternate how it’s run or who facilitates the meeting. Sometimes you could walk the board and other times maybe go around the room to see if people have any questions or concerns about the work that is being done. In a team I am fortunate to be a part of we sometimes play short games now and then, keeping things fun and engaging.
Retrospectives
I’ve attended many retrospectives over the years where we spent over an hour discussing what we liked, didn’t like, and would like to change and each retro we’d be discussing many of the same things over and over again. This resulted in many people not wanting to raise anything because they felt like they weren’t being heard or that things wouldn’t get addressed and so it felt pointless to them.
If you do retrospectives and actions/tasks are raised, try to ensure you choose 2 or 3 that you will try to do before the next one. Do not fall into the trap of trying to action everything that was raised. From experience, whenever I’ve seen teams trying to do this they often fail. This then leads to people becoming frustrated and not seeing the value of raising actions in retrospectives. Ensuring each action/task has an owner also really helps. Ask people before the retrospective ends who would like to own each action/task.
The end of stand-up is a great time to remind teams of the agreed actions/tasks, have any discussions and/or get help to achieve them. It doesn’t have to be every day but a little reminder helps ensure that they aren’t forgotten.
It might also be that you do not need a retrospective. Don’t blindly just do one because you’re ‘being agile’ or because another cool company that you’ve read about does one. Maybe a check-in with the team and/or a temperature check is all your team needs.
Jira - lots of swim lanes
Something I’ve seen many teams do over the years is have lots of swim lanes on their Jira boards. The hope of doing this for teams is that they will know the state of each item on the board for visibility.
Typically, what you see in the real world is a Jira (or other project management tool) board with many swim lanes. The problem with this though is that people begin to stop talking to each other, instead relying on the swim lane states to tell them the progress of each item on the board. It also slows down getting the thing done and is often used as an excuse to bring in more work. Another issue with this is it creates silos within the team, for example having a testing column where things can be chucked over the fence.
I’ve worked on and observed many teams where they have swim lanes for review, doing/in-progress, in review, in test, done, ready for demo, done done (what does that even mean…) plus many other weird and wonderful swim lanes.
Really, what is something that’s in progress? This is something that is being worked on to meet the agreed definition of done (hopefully you have these in your tickets). Tests should be written as you develop, it’s not a separate thing, if you have something reviewed it might require rework so it’s still in progress. If it doesn’t meet the definition of done, do you think it’s done?
Jira - test or in test swim lane
Test or In Test columns are a really bad idea. A whole team approach to testing means there are no silos. Sadly a familiar pattern I’ve observed within many engineering teams is that much of the testing is left to testers. This is a massive topic and could be a bunch of different blog posts but the whole team should be invested in testing, regardless of what’s being tested. It’s the team’s responsibility and having a separate column just for testing will lead to engineering teams working in silos with things being thrown over the wall.
With teams working in silos, this leads to people not understanding what has or hasn’t been tested. A familiar smell is where there are lots of automated tests implemented at the UI level.
I’ve asked previously several different testers:
“Why are there so many tests at the UI level?”
Their responses varied but were things like:
“I’m just covering all the bases”
“I’m not sure what they’ve (the developers) tested exactly”
“I’m giving us extra coverage”.
These things could be easily remedied by just talking, working together, as a team. It benefits everyone to work in this way. It leads to a more collaborative team with tested code that gives the team faster feedback, giving them confidence to make more informed decisions.
Testing isn’t something to just bolt on at the end. We should be testing assumptions, requirements, designs, code as it’s being written and many more things I’ve not mentioned here, testing all the things as we go.
Jira - blocked swim lane
Many of the times I’ve observed tickets moving to a blocked state have been for a few reasons:
- The ticket isn’t ready…
- Not answering as many questions as possible upfront
- Ticket isn’t as small as reasonably possible
- Team too keen to get work into the TODO column
So the above isn’t an exhaustive list but tickets need to meet the definition of ‘ready’ (your team should agree what ready and done looks like) and be achievable. If you still have questions are there any that can be asked/answered before committing to deliver the ticket? Is the ticket small enough to get done in a reasonable amount of time? If the ticket cannot be broken down any smaller, could sub-tasks be used so the team can split the work so if a higher priority work item comes in it’s clear by looking at the sub-tasks what has or hasn’t been done rather than all the work bundled into one ticket.
A very simplistic example of this might be a team that has a ticket to update 5 repositories that they own to amend a readme piece of text. Whilst the work might be simple, a much higher priority piece of work might come in by the time you’ve updated the third repository and so by using sub-tasks for each of the repositories you clearly indicate what has or hasn’t been done. Of course, you can add comments to a ticket to indicate this and each approach has its place.
In teams where I’ve worked, we’ve had 3 amigo sessions on tickets. Do not be afraid to keep 3-amigoing tickets. If you aren’t sure that a ticket is understandable and achievable don’t move it into a state i.e. ‘Todo’ where the team might pick the work item up, take it to another 3-amigo session.
Pull Requests (PRs)/Changes to codebase
The last few clients I’ve worked with have all used GitHub as a place to store code. Regardless of if you use GitHub, changes should (unless your in a team of just 1/yourself) be reviewed. This helps to ensure you are writing code and/or documentation that is simple, maintainable and agreed to be good enough at that specific point in time.
PRs lost in all the noise
Many of the teams I’ve had the pleasure of working in have had their own dedicated channel for the team to post messages, asking for help etc. On my existing team quite often we would share links to PRs in our team channel to ask others to review and provide any feedback.
The problem with this was that of over 10 people and with many people working on different things, messaging about work and non work related things, alerts being shared in the channel etc, often messages asking to review PRs were getting lost. Individuals would need then need to remind the team of the PR and dig out the message to ask them for approval.
To combat this we created a new channel specifically for Pull Requests. Whilst simple, this has been effective in ensuring all work requiring approval is in one place. As a team we add comments/provide feedback, but also use emojis to indicate if something is being looked at, has been approved, merged etc.
Within our team all repositories have merge protection which means nobody can commit code directly to the main code branch. Every change needs to be made on a branch and a pull request made to merge in, every pull request requires at least one review. I know people will have lots of opinions on this approach but it’s decided at an organisation level and something whether I agree or not with I cannot change ;-).
Lots of comments on PRs
Often I’ve observed people adding lots of comments on PRs. Whilst it’s great somebody is taking the time to go through and pick things out to discuss or flag, this is a really slow feedback loop.
To improve this there are a few different things you could do.
- Pair where possible (or by default)
- Jump on a call instead of filling a PR with comments and do a review
- If there are changes that are required, don’t just add a comment, why not create a commit or patch with the proposed changes?
There was one team I worked on many years ago where I think an individual felt that adding lots of comments to a PR showed that they were really busy - or they’d get gold stars or a pat on the back :)). Don’t be that guy, shorten feedback loops, work together!
Pairing - Shortening the feedback loop
If you can, why not pair? By pairing you are constantly discussing/reviewing what is being written and reworking as you go.
One common issue I see with teams who pair and have PR approval setup is that they might pair with one engineer but then share the PR for somebody else to approve within the team.
Imagine we’ve been pairing with another engineer called Toby to implement a piece of code. If we hadn’t have paired with Toby would we have accepted their approval of our work? Would we still have asked others in the team to additionally review the work despite the fact we only require one approval before the work could be merged? Whilst pairing with Toby we would have been reviewing, discussing, implementing and refactoring as we worked together.
Perhaps sometimes for a larger/more crucial change you might want to have more eyes on what is being done but maybe that’s an opportunity to swarm with more of the team whilst doing the work rather than just pairing with an individual.
What about you?
What challenges have you seen whilst working in a remote team? How have you overcome them?
