Many claim that software development teams are the most effective when they are all in the same place and are able to collaborate freely. Others would argue that it was possible for a team to collaborate effectively when they are remote.
Having worked in both settings, I’d say they’re both right. What’s more, I’d suggest that moving forward there isn’t a stark choice between having teams that are always collocated or completely remote, the answer is probably somewhere in the middle and will be different for every organization.
The key to making remote work effective for technical teams is to ensure that they are able to effortlessly communicate much to the same degree they would be able to if sitting in the same room.
Here are some remote hacks I’ve learned from working remotely with a technical team, both when it was a choice and when it was a necessity.
General remote work hacks
1. Trust your team
One of the most commonly cited arguments for not working remotely is that it is more difficult to keep tabs on everyone on your team to make sure they’re working.
It is true that when everyone on a team is spread out it can be more difficult to know whether they are working. And it completely misses the point.
Instead of coming up with all kinds of convoluted mechanisms to monitor your team, you need to instil the most powerful remote work policy: We trust you.
Establish a shared understanding of the outcome you seek.
Provide sufficient guardrails for them to make decisions.
Provide the team with an environment in which they can be successful.
And trust that your team will do what needs to get done in order to make that outcome happen. Instead of worrying that your team won’t do anything, you may just find that you have to throttle them back a little bit and remind them to step away from work to stay refreshed.
Unfortunately, not everyone in your organization will follow that philosophy. Especially if your organization is new to remote work.
You may have people ask you to keep your video camera on all day. You may see additional meetings pop up on your calendar to “check-in” and see how things are going. At the very least you’ll have people trying to have all the meetings that would have happened if you were all in the office.
Don’t do any of these things!
If you act like you don’t trust your team you will end up with a team that you truly can’t trust.
Take this opportunity to change some of the behaviors you see teams practice in offices that might get in the way of being as effective as they can.
2. Don’t recreate bad in-person working practices
My piece of advice when comparing working in an office vs working remote – don’t try to replicate what you do in an office setting when working remote. Namely, don’t replace all of those in-person meetings with video conferences.
Use this opportunity to take a long hard look at those meetings and decide which ones are actually relevant and useful.
If they aren’t useful, or the purpose of the meeting can be accomplished through other means, try those other means out.
3. Establish a shared understanding of your outcome
I mentioned above that you need to trust that your team will make the right decisions that will keep you progressing toward your desired outcome. To make sure they are successful with that, you need to make sure that they understand the outcome.
And I mean really understand it. To the point where everyone can pretty much describe the outcome in roughly the same way.
You want everyone to understand the problem you’re trying to solve and why.
I like to use a couple of different techniques to guide the conversations about outcomes - the problem statement and the opportunity assessment. I generally use these techniques for face-to-face discussions during discovery sessions, but you can make some slight modifications to do them remotely.
You have these conversations so that you can give everyone a chance to verbalize their current understanding of the desired outcome, then have a structured conversation to come up with what the outcome should really be.
Including people in a discussion about the outcome is more powerful than asking them to read about the outcome.
If your team members are involved in a discussion about the outcome, they can think about it in terms meaningful to them, they can gain clarity, and they have a better guide to decisions they need to make on a day to day basis.
4. Clarify responsibilities
When you work remote, it’s helpful to have clarity around who is going to do what. This is important for the entire team, and it’s especially important if you have people on the team whose responsibilities could overlap. For example, you have both a product manager and project manager, or there may be multiple roles that could do automated testing.
There’s not necessarily one best approach to identifying who does. It really depends on your particular context, the people on your team, and their skills and interests.
You should also come to an agreement on who is going to make what decisions. It’s helpful to have clarity on that regardless if you’re working remotely or not, but it’s especially important when you work remote. When you know who is going to make decisions ahead of time, it prevents discussions about who should decide when a decision comes up. It also prevents people from stepping on each other’s toes.
5. Clarify communications
When the pandemic first hit in March of 2020, I was working with a colocated team that pair programmed quite frequently and was very effective using conversations in the team room to solve problems and help each other out.
When it became more and more likely that we would be working remotely we had a discussion about how we wanted to handle it. The main practice we adapted was to have an open voice channel on Slack during our core working hours. We all agreed we didn’t need video, and most of the time, everyone stays on mute.
We’re not using the voice channel as a means of keeping tabs on everyone. For a lot of quick questions, the team members message each other via text and only jump on the voice channel when a discussion makes sense. It’s not to monitor the team to make sure they’re working, it’s to re-create the advantage we had working in the same room.
This approach works because the team trusts each other. When we discussed how we wanted to proceed, we didn’t talk about whether people were going to do their jobs, we just focused on what would work best given the situation.
Your team needs to be clear about how you expect to communicate with each other. That includes how you’ll handle quick questions, what tools you’ll use, where you’ll record different types of information and how you’ll want to handle different interactions.
The next section describes the tools and techniques I’ve found helpful for the usual interactions you’ll see on a product team.
Because many agile coaches insist that face to face is the only way for a team to interact, I explore how each of the ceremonies from the Scrum framework can be done remotely.
Please don’t read this and quote the Scrum guide chapter and verse back at me, these are techniques that my team has tried and found to work.
Remote work hacks for specific interactions
6. Backlog refinement
If you’re working remote, then you are more than likely using a backlog management tool such as Jira or Microsoft Azure DevOps (I only mention those because they are the tools I have experience with lately.)
Regardless of the tool, I find it helpful to visualize the backlog in a couple of different ways. I like to visualize the progress of backlog items in the team’s refinement process using a discovery board. If you’re using Jira, you can create a separate board (using the Kanban Board functionality) to make a discovery board. If you’re using Azure DevOps, you can establish your discovery board columns as part of the board view.
Figure 1 An Example Discovery Board
As backlog items progress along the discovery board, they get more refined and get more information behind them. Your team will want to come to an agreement on what information needs to be in a typical backlog item and encapsulate that agreement in a definition of ready.
My last team ran refinement sessions using the open Slack voice channel I mentioned earlier. I’d share my screen showing our backlog board, open up the top item in the Refinement column (see Figure 2 below) and briefly describe what the backlog item is about. Then the team asked questions, provided comments, and we’d discuss things that may be a little unclear. All along I made notes in the backlog item based on our discussion.
Figure 2 Another Discovery Board
Each team’s discovery board and definition of ready will be different based on their particular context and need. One team I worked with was comfortable sizing items before they had been fully described. Another team I worked with preferred to size a backlog item once it’s fully described.
Agreements about what your team needs to start development and the steps in your refinement process will evolve over time. You’ll also want to regularly revisit those agreements as you learn what is enough or too much to record in the backlog items.
7. Sprint planning
When you do sprint planning, fire up a Zoom meeting, share a view of your backlog tool and focus on items in the column you’ve designated as holding items to consider for Sprint Planning, such as the Ready to Rock Column in Figure 1.
Start by getting agreement on what you want to accomplish in the sprint which you may want to define as your sprint goal. Next, discuss your anticipated capacity for the upcoming sprint.
Then, discuss each item in the ready for Sprint Column briefly. Ask the team if they feel comfortable including that item in the sprint. If so, move that item over to a ready for dev column and move to the next item. Continue that process until the team feels that they’ve “filled up” the sprint.
When I work with a team that uses a flow approach we generally don’t have an explicit planning session since items flow across the board.
When I bring new items into the Ready for Development column that jumps some things that were already there I make it a point to mention to the team and check that they are ok with the change in the order of what’s next. I’ll usually ask the team that during stand up along with an explanation of why the order changed.
8. Standups
For standups, we’ll share the backlog tool and focus on the items that are in active development or testing. I refer to this as the delivery board. We start at the items that are being tested and get a quick update and then walk backwards to get quick updates on the items that are under development.
Figure 3: Example Delivery Board
After that, I ask if there are any “standup-y” items to discuss. This is when members of the team will bring up any obstacles they’re running into or let us know if they will be away from their computers for a bit during the day.
We went away from the questions three because it felt too much like a status report, and it didn’t necessarily guarantee that we’d discuss every item that was in progress.
9. Sprint reviews
For sprint reviews, I’ll typically use Zoom because there are people included who are outside of the team involved. We’ll put together a few slides providing an overview of where the project is, mainly due to a request from the organization we’re working for right now.
After sharing a few key pieces of information I’ll demo any new user-facing functionality the team produced. Then we’ll open things up for discussion.
10. Retrospectives
When we do retrospectives, we follow the action-focused retrospective approach I wrote up in a recent technique brief. When we do our retrospectives remote, we’ll use the Slack remote channel and then share a tool that allows for team members to write anonymous notes in one of a set of categories. You can use “Good”, “Meh”, and “Bad” as shown in the example below, or another set such as “What went well”, “what should we do differently”, “what did we learn”, “what still puzzles us”).
Figure 4: Action-focused retrospective approach
My current team uses Azure DevOps, and it has a Retrospective feature that does a good job of mirroring the various steps in our action-focused retrospective approach.
If you don’t use Azure DevOps, you can use Google Docs as a good replacement.
Find these remote work hacks useful?
If you found these remote-work hacks useful, please share them with your team and with others who you think might find the value out of them.
And, if you’d like notification of when we post more useful content like this, please subscribe to our newsletter.
About the author
Kent J McDonald writes about and practices software product management. He has IT and product development experience in a variety of industries including financial services, health insurance, nonprofit, and automotive.
Kent currently practices his craft with teams in a variety of industries and provides just in time resources for product people at KBP.media and Product Collective. When not writing or product managing, Kent is his family’s #ubersherpa, listens to jazz and podcasts (but not necessarily podcasts about jazz), and collects national parks.
Kent J McDonald
CometChat
