The age of remote work is here.
Well, for many development teams, it’s been here for quite some time now. COVID-19 just helped us convinced the boss that you don’t need to be in the same room to make moving a project forward possible.
As the office moves away from physical spaces and adopting digital ones instead, your team might be part of the crowd that’s migrating towards a fully automated and remote workspace.
While we may cheer to no more traffic jams and long commutes, you’re still required to telecommute into the office via your Internet connection. Your team might already be remote – but not at the levels required to function as effectively as possible.
Here’s how to navigate remote work as a team and make sure that your projects continue to ship within a certain level of quality and on time.
If you’re working with an agile framework, there’s a high chance that you’ll have some sort of kanban board sitting in the office. Colorful sticky-notes plastered all over each column, each moving along the lanes as the project progressed in a particular direction. A sea of back-log and unscheduled tasks may sit somewhere nearby, with tickets lost or demoted down the priority list.
There’s something special about having a physical kanban board. The materialness of its presence makes it real against the intangible process of creating code.
As developers, when we make code, it’s hidden in between the forest of files, folders, curly braces and thought processes. A kanban board helps us visualize this.
When you move away from a physical office where everyone sits together in the same room, this board is no longer possible – unless you digitize it.
There are numerous ways to digitize a kanban board – but tickets are useless unless developers actually look at them. The purpose of kanban and agile is to give developers visibility and accountability.
The physical board is something that sticks out when you’re sitting in an office. It’s always there. Everyone knows its there. When someone walks past it, the tickets hold a particular weight of responsibility and ownership over them.
You can digitize everything – but if the workflow doesn’t endorse it, then trying to replicate a digital version of the office won’t work.
Going digital can cause havoc on this because it can take effort to see the kanban board. You have to make a conscious decision to go and look at it. So how do you fix them?
The easiest solution is to make it part of your workflow.
If your code workflow already sits with GitHub, there is a projects feature that allows you to set up lanes and ticket tasks with a kanban vibe. It doesn’t matter what you’re doing, if you’re already in GitHub to push, pull, review, approve or do something on the platform, you’ll find yourself looking at the digital board.
Its proximity to your work is akin to the physical proximity it had when you were sitting in the office with the rest of your team.
This may sound strange but when you reduce your deliverable size, you can fit more of them in a delivery cycle. While the actual workload might end up being the same, you’re going to need visibility and movement when you’re in a remote environment.
Teams often lose contact with one another once they go remote. There’s a chance that they can get lost in their own tickets and cease to communicate with one another. The bigger the ticket, the higher the chances of this occurring.
Unless you were originally remote by design, moving from a physical office into a remote space can cause result in broken communication and slower completion of deliverables. The transition phase is a precarious time and breaking down your deliverable size can help you determine your efficiency factor as a team.
Rather than banking on large chunks to be delivered, smaller tickets can mean you’re able to fine tune the burn down rate. It’ll also help you identify potential bottlenecks faster and therefore resolve issues as they turn up.
It increases the visibility of a potential issue as code gets pulled more for review and commits happen in an increased frequency. When issues turn up sooner than later, it facilitates earlier forms of communication.
The actual amount of work might end up being the same but the movement forward is much more granular in approach. When large tickets are broken down into smaller parts, it’s easier to replace or delegate the tasks between team members.
While communication is key to staying on the same page and making sure that everyone understands where they fit into the team and the work that’s expected – there is a thing as too much communication, especially in a remote and digital setting.
It’s easy to just walk up to another dev and ask for their help. It’s a bit different when you’re working remotely.
Keep your communications at a minimum and avoid long email chains that involve more than just the two people talking. Why? Once you add a third or fourth person, it’s easy to accidentally miss someone out in the chain or it becomes too long and hard to follow.
Tracing a conversation in emails can be a pain. The act of communication itself is not the issue. Rather, it’s the presentation of how emails work.
For official pieces of information where it won’t turn into a long chain, email is not bad. For conversations that requires bouncing back and forth, problem solving and collaboration – email is not the right tool.
Reducing points of digital contact can reduce the amount of time a developer needs to break away from the act of working to converse with their peers. Talking is not a bad thing. Spending time trying to figure out what everyone is thinking and finding out conclusions to conversations is where the time sinks happen.
Most of the time, your team only needs two things – a space where they can communicate and converse in an unstructured manner, and another to document and create progress tracking.
When you leave a team to self organize and facilitate the required communication channels to meet these two vital needs, remote work becomes a breeze. It will help maintain project clarity and ensure that everyone understands the what, the who, the when and the where things are happening.
Successful remote teams are often defined by their ability to remain organized through the communication and planning interfaces implemented. If your team is already working well in an office setting, then moving into remote work won’t be much different.
Developers are smart people by design and nature, with a good pinch of tech savviness to figure things out without the need for handholding. Most of the time, there just needs to be someone to monitor and ensure that communication stays open, frequent and organized enough that it doesn’t slow down the project deliverables.
Diligent cleaning and archiving of communication spaces is also required to prevent walls, threads and chats from being clogged up over time by past projects, tickets and discussions.
It’s also a good idea to let your teams be self organizing. It’s easy to try and enforce rules and methodologies on them – but developers are at ground zero of the code work.
They know what they need and will figure out the shortest path possible to get it. If a particular communication channel or methodology is working for them, don’t try to enforce something else into it, unless everyone agrees that it is better and more effective.
When you give a group of developers a set of clear requirements and flexible framework to deliver it, you give them the ability to think and grow as a team and as creative thinkers – especially in a remote environment.