7 best practices for remote agile teams

Remote and distributed teams can excel at agile software development, but it takes work and experimentation. Let this be your guide

Contributor, InfoWorld |

7 best practices for remote agile teams — dem10 / Getty Images

Agile methodologies work best when everyone on the team is together in one location. When teams share a workspace, it’s easy for teammates to ask questions, pair on programming tasks, and solve problems without scheduling meetings. Using technologies like web conferencing, group chats, and email just isn’t as effective as direct, person-to-person interactions.

That said, organizations can make agile methodologies excel with remote and distributed teams, but it takes some work and experimentation. Team members must find the optimal use of technologies and adjust to communication styles to ensure team productivity, collaboration, and quality.

With the outbreak of COVID-19, many agile teams must shift from working in offices to working remotely. This will be a new experience for many people who have not worked at home for a significant part of their careers, and for teams accustomed to in-person interactions. Furthermore, some team members may fall ill or face other hardships due to the growing pandemic, so agile teams must adjust to a new way of working.

This article is a simple guide aimed at helping team members, teams, and organizations transition from primarily in-person agile teams to highly distributed ones.

Choose proper equipment, tools, and working space

If you’re going to be working remotely, then make sure you have a setup that works for you, your company, and your team. Think of it like an office move and invest the time up front to evaluate the options and make sure you have everything you need to be productive, comfortable, and in a space where you are least likely to be distracted.

Consider these 12 considerations when working remotely for extended periods that include recommendations on work disciplines, workspace, equipment, network, and tools.

Some changes you will need to make won’t become clear until after you get started. If you have poor connectivity, you might need to relocate the wireless router or switch to a wired connection. The location of your desk may need adjustment if you’ll be doing a lot of video conferencing. You will probably have to tell family members to keep a distance when you’re working.

Be present and converse with teammates

Agile teams succeed by balancing the time devoted to collaboration with the time devoted to the concentrated efforts required for coding and other development activities. In the office, it’s a little easier to see a teammate’s focus, and disciplined agile teams find ways to avoid distractions and context switching.

When working remotely, teams have to be online but also share their availability. Tools like Slack and Microsoft Teams allow you to set availability status while other collaboration tools enable you to mute notifications. Using the status settings is critically important when teams are open to flexible working hours.

Agile teams must schedule time for formal collaboration sessions and to do the work to complete user stories, but team members should also engage in small talk. People respond differently to times of stress, and to working remotely, so it’s essential to check in with one another. Also, people have different communication styles online versus in person, and there’s a new opportunity to get more people involved in online conversations.

Scrum masters, technical leads, and product owners should regularly ask the team questions about their level of understanding around requirements, blockers to their progress, and if there’s anything they need to improve their productivity and happiness.

Lastly, scrum masters and technical leads from multiple teams should be in regular contact with each other. Their experiences and issues managing their remote teams are probably not unique. Sharing any learnings on how they are getting their agile teams to collaborate remotely would undoubtedly benefit the whole group.

Review approaches to agile ceremonies

Agile teams shifting to remote collaboration shouldn’t have to redesign their process or do away with agile ceremonies. But going remote may require scrum masters to rethink how to conduct the meeting, depending on the size of the team and the available collaboration tools.

For example, in-person teams looking over the scrum board during the daily standup will need to devise a digital version of this ceremony. If the team is small and historically has experienced relatively few blocks impeding the work on user stories, then they may be able to do away with a meeting and replace it with a scheduled chat gathering.

Other suggestions for remote agile teams:

Use digital whiteboard tools for sprint planning and design sessions
Set up video web conferencing for commitment meetings
Select one person to screen share during sprint reviews
Use surveys or low-code applications to capture feedback at retrospectives

Commit to realistic team and individual assignments

Agile teams shifting from in-person to remote collaboration have to reset their sprint velocities and review the level and complexity of work they can realistically commit to and complete. Scrum masters and agile leaders should apply practices similar to newly formed agile teams and allow teams to adjust to new ways of working.

For example, committing to complex user stories that require contributions from multiple team members is ill-advised because some teammates may become unavailable during the sprint. If possible, these stories should be broken down into smaller ones or delayed if the product owner is able to de-prioritize them.

Similarly, agile teams may want to avoid committing to stories that have dependencies on work by other teams. The additional collaboration may take a couple of sprints to define for newly formed remote teams.

Increase the level of documentation

Agile development teams prioritize working code over up-front documentation, but that doesn’t mean that documenting architecture, APIs, and code isn’t necessary.

Teams working remotely for extended durations may want to discuss documentation standards and see if more significant efforts are warranted. Sometimes, documenting the code can replace some of the in-person implementation discussions around how a code module works or how a teammate is addressing technical debt.

Invest in spikes, CI/CD, and addressing technical debt

Teams expecting to work remotely for extended periods may find it easier to focus on more technical stories rather than ones that require interactions with the product owner and stakeholders. For example, instrumenting a multi-step user experience involves collaboration between the product owner, designers, developers, and testers. It may be harder to coordinate discussions or develop a shared understanding of end-user needs when teams are just starting to work remotely.

There are other opportunities to prioritize work that require less collaboration and more individual concentration and innovation. Prioritizing small spikes to test new ideas is one example, especially if a developer can work on a short proof of concept with few interruptions or context switching. Another option is to prioritize addressing code-level technical debt, especially refactoring code modules, adding unit testing, or improving exception handling. A third option is to invest time to develop or improve CI/CD automation.

These more technically challenging assignments also help developers concentrate on completing a job in areas where they see the benefits directly.

Review deployment strategies and reduce risks

Highly collaborative agile teams learn to work together like high-performance hockey teams. In hockey, even though the puck moves fast and can bounce erratically, players use a mix of designed plays and improvisations that enables both strong defensive play and explosive offensive play.

Now move this team from an indoor arena and ask them to play on an outdoor lake, and they’ll need some time to adjust to the elements. They’ll play conservative defense for a while until they get comfortable with the new environment and regain their rhythm.

The same is true for agile teams and agile organizations of multiple teams. It’s true whether the teams are working on legacy systems or building cloud-first applications using the latest devops practices.

The conditions that require agile teams to work remotely will likely impact other aspects of the business including operations, customer expectations, and supply chain dynamics.

Customers and end-users may not want the same deployment frequency, especially if that frequency risks the reliability or performance of the application. If you have APIs that work with your business’s suppliers, those suppliers may be less accessible to participate in testing the changes. If the software application is subject to compliance or regulatory oversight, then it might be harder to get the required reviews and approvals.

Agile teams must recognize the broader set of changes impacting their organization’s business model, customers, and working environment. The organization principles that drove everything from the speed and frequency of deployment to the types of work and user stories that get prioritized will need to be reviewed from a new operating perspective.

A big part of being agile, and not just following agile practices, is recognizing when and how to change.