4 Practices for Software Teams Working from Home During COVID

Like many people around the world, my team has spent much of 2020 working remotely due to COVID19. Our team tools and processes were designed for a small office environment. Suddenly we were all transported to our home offices, kitchens, and other improvised work areas.

Through a bit of luck, hard work, and rapid iteration, we’ve found practices that allow us to continue to shine as an agile team. Meetings and collaboration may never be quite as seamless as they are face-to-face, but this is offset by fewer interruptions during heads-down work.

I was initially hesitant to write yet another article about working from home during COVID. However, I’ve realized many software teams are still struggling. Here are four practices that can help your team thrive while working remotely.

Photo by Pankaj Patel on Unsplash

Use Slack Effectively

Slack, Microsoft Teams, or a similar product is probably a core part of your remote communication toolbox. While these tools are excellent, a few guidelines can help to maximize communication and minimize distractions:

Reply using threads

Follow-ups to a post or request should almost always happen in a thread, rather than in the main channel. Use “also send to channel” if you need to draw in additional people.

How it helps: Users of the channel are notified or have a chance to scan the initial post. If they are interested, all the relevant information is grouped together for follow-up, even if there is more than one active conversation in the channel.  When replies happen in the main channel, everyone is forced to scan every message or risk missing a new topic.

Keep channels specific

Set a clear topic and audience for each channel. Stay on topic and boot out people who don’t belong there. Post new items or questions in the most specific appropriate channel.

How it helps: Maximizes targeting of messages to the correct audience. Allowing extra users into a topic will result in people getting sloppy and abusing the topic. 

Think before you interrupt

Direct messages, @user mentions, and @here interrupt the people who get them.  Before you do it, think “would I interrupt all these people in person?”

How it helps: Studies show that even short interruptions cost significant time and/or stress. It’s far more effective to take a moment to reconsider before interrupting dozens of your colleagues.

“only 10% of the sessions have programming activity resume in less than 1 min after an interruption”

– Parnin, C., Rugaber, S. Resumption strategies for interrupted programming tasks. Software Qual J 19, 5–34 (2011). 

Avoid direct messages for design

Prefer a thread in a team or topic-specific channel to direct-messages for design decisions.  

How it helps: Using a public channel makes discussion available in case you need to look back or quickly loop someone else in. Using a thread avoids unnecessarily distracting people with each back and forth.


Introducing some basic guidelines and sticking to them can ensure that you are using Slack to communicate well, while minimizing the time drain and distraction for your team.

Decide on your rules, or guidelines, share them, and lead by example.  Nudge and remind people but don’t become too militant about it – remember to prioritize individuals and interactions over processes and tools.

Asynchronous Standups are Ok

We now use a mix of live video standups (Zoom) and asynchronous standups (Slack). 

Although video standups are the closest thing to being in person, they don’t bring any benefits, other than letting you stay remote.  

Using a slack thread, which every replies to in point-form, is less interactive, but it also gives people more flexibility. Instead of interrupting everyone at a fixed time, they can give their update as soon as they settle-in for the morning. To retain some structure we do have a cut-off: team members should post their standup update by 10am. This also provides a time when you can scan everyone else’ updates. You may want to use an earlier or later time, depending on your team.

Use the team slack channel. It should have everyone who would normally attend standup. Avoid using a channel with people who are not part of the team: it will distract them and may lead to less candid updates. 

Stand Down

I also suggest an end-of-day thread. We structure it similarly to stand up but letting everyone know how the day went.  This is a quick way to check who’s still in the office in the evening and to notice if people are working late.  An occasional late night is ok, but some people need help setting boundaries when working from home to avoid burnout.

How it Helps:  The “stand down” or “Sign off” thread helps to replace informal communication that would happen naturally in the office. Using an asynchronous format keeps it from consuming too much time.

Dual monitors above laptop
Photo by Joshua Aragon on Unsplash

Make Use of Dual Monitors in Meetings

Most online tools, from Google Docs and Office 360 to Confluence, now support live multi-user editing. Instead of the traditional “presenter-audience” model try this for your next meeting:

  1. Setup a template or agenda, with space for edits
    1. If you’re planning a brainstorm or similar activity, create lots of empty space or bullets so that people can contribute without overwriting one another.
  2. Send out the link in advance, or at the start of the meeting
  3. Invite people to follow-along and contribute directly themselves

You can have this open on one monitor (or one side of your screen) while you have your conferencing system open on the other. This can bring back some of the collaborative white-board feel using very common tools.

If you are stuck presenting because live edits are impossible or don’t update quickly (looking at you JIRA) you can still present on using one monitor and have your team up on the other.

How it Helps:  Non-verbal communication is important, especially in larger groups. You can quickly read the body language of each team member, but only one person can speak at a time.  Leveraging extra screen space so that you can see your team while presenting can provide this feedback while working remotely.

Your team is probably tuning out during long video conferences meetings. There is a better way!
-Photo by Magnet.me on Unsplash

Minimize Large Meetings: Sprint Planning in Squads

Large meetings are always a drag, and video conferences make them even worse: “…… It’s ok, you go first”

On the other hand, meetings of two or three people translate to a virtual environment with less loss of productivity. How can we apply that to improve virtual sprint planning?

A mentor and I developed a technique we call “Squad Planning”.  This was originally designed to help us manage an agile team that was getting a little too big, but it’s also a great help for remote work. The idea is to break sprint planning into three phases:

Squad Formation

Set the high level objectives for the next sprint. Group the work into a small number of topics. One squad will work on each topic. Your product owner and scrum master set the objectives, decide about how many people need to be on each squad, and give a high level overview. I suggest topics sized so that squads are 2-4 people.

Squads then form by voluntary sign up. This is similar to usual sprint planning for many teams, except that each person is generally signing up only for one squad. Encourage squad members to decide where they should be first, then rebalance.  To answer two common questions:

  1. In some cases it does make sense for the team-lead to pre-select one or more squad members who have the requisite context or skills.
  2. Most teams will “rebalance” themselves, if they can see a project is understaffed. From time to time the scrum master or team lead may need to give a nudge, but I bet it will happen less often than you expect.

Pro Tip: There’s something energizing about giving the squads fun names. For example, two recent squads working on water analysis and reporting were named “Atlantis” and “The Accountants”.

Squad Planning

Individual squads go through their topics in the backlog. They elaborate on any outstanding details or questions and sign up for a quantity of work they think they can complete next sprint. During this time the product owner and other key stakeholders should be available to answer questions.

Allow at least a few unstructured hours for this. Some squads will need the time. If other squads are done early, they can get started or wrap up some other small tasks.

This is the majority of the work that would normally happen in sprint planning. It’s still happening collaboratively, but in smaller groups. These work better than one big conference because everyone is either fully engaged, or free to work on something more productive.

Sprint Planning (Review)

Finally, we all get back together. Each squad presents their plan and commitments to the whole team.  This isn’t a detailed audit of their work, but rather a chance to make sure everyone is on the same page and to offer or request help. This meeting is usually very quick.

How it Helps

By breaking sprint planning into stages, the amount of time spent in a full-team meeting is significantly reduced. This general idea can be applied to other large meetings:

  1. Communicate the high level goals broadly
  2. Form smaller working groups to complete the work
  3. Bring it all together and get broad buy-in

The Usual Advice Also Applies

This article has focused on practices that I didn’t see elsewhere when we started working remotely. 

Other practices that are valuable, but are already well described elsewhere include:

  1. Maintain regular hours – Having a schedule helps keep people balanced. You want your team working a normal number of hours.  You probably also want them working during the day – while some people may thrive with very odd hours, there are others for whom this is an unhealthy trap.
  2. Don’t maintain the same hours – If your team is working from home, one of the advantages is that they don’t need to commute. Allowing more flexibility, within bounds, is a great way to derive a positive benefit from this change.
  3. Over communicate and set clear expectations – miscommunication is easier and it takes longer to notice that something has gone wrong if you aren’t physically working in the same space. 
  4. One on ones – I think these are always a great idea. When working remotely they give you an opportunity to check in with each team member and see how they are doing which might otherwise be missing.
  5. Maintain social connections – Office work is, to a greater or lesser degree, a social experience. If your team members aren’t used to working from home, they just lost this. As a leader it’s up to you to help them get a little of this back with things like team lunches or other informal virtual gatherings. 
  6. Encourage good ergonomics – You’ve probably already figured this out, but you and your team members need a comfortable work space.

Put it into action

Starting tomorrow, you can

  1. Decide on Slack/Teams guidelines and share them with your team – or just point them at this post.  Lead by example and gently remind people of Slack etiquette. See if you notice your channels are easier to read. 
  2. Introduce asynchronous standups or sign-off

Over the next month, you can

  1. Use the dual-monitor approach at your next collaborative team meeting.
  2. Give squad planning a try
  3. Let us know how it went in the discussion forum below


Is there a technique I didn’t mention that’s worked really well for your remote team?

Are you struggling with a problem not addressed above?

Use the forum below to share your successes or challenges right now. Together we are going to rock agile software development from home!

The forum is moderated and your first post may not appear until it has been manually approved.

Leave a Comment