7 best practices for remote development teams

Distributed software development teams are here to stay. Take advantage of these best practices to overcome the challenges of working remotely, keep agile teams agile, and maximize productivity and quality.

7 best practices for remote development teams
Dean Mitchell / Getty Images

Application development and agile teams have been working remotely for most of the last year. Developers figured out how to use Zoom, Microsoft Teams, and Google Meet to run virtual meetings. Some use Slack for asynchronous communications, while others focus on the collaboration capabilities built into agile tools like Jira, Azure DevOps, and Asana. The top remote development teams also enhanced their CI/CD pipelines and other devops automations to reduce toil and address error-prone processes.

Going beyond the basic collaboration practices is essential for remote development teams. According to a recent survey, 65 percent of IT executives said at least a quarter of their workforce would continue to work remotely. And in fact, companies offering more remote working opportunities may be a good change. A second survey on the future of work and software development reports that almost 60% of respondents increased software developer productivity when working remotely.

So if developers working remotely is a new norm, what should agile development teams do to maintain productivity and software quality—or better, turn them up another notch? I focused on collaboration in previous articles on remote practices for agile teams and remote devops and engineering teams, including running meetings and knowledge sharing. In this article, I suggest seven more best practices around the application development process.

Use continuous agile planning to maintain roadmaps and backlogs

The development process should begin by discussing goals, priorities, and requirements with the agile product owner, the development team, and other stakeholders. These discussions lead to story writing, estimating, and developing solutions.

Robust, innovative, and secure software solutions often require more than one sprint of planning. Furthermore, most business stakeholders want visibility into the release plan and roadmap to plan for digital transformation change activities such as marketing for customer-facing applications and training for employee experience applications.

It’s hard to accomplish this level of planning if teams only have backlogs for the upcoming one or two sprints, and organizing quarterly planning meetings is less productive for remote development teams.

A best practice is to plan continuously by adding, estimating, and prioritizing features and stories to the backlog every sprint. The best teams aim for at least four sprints of a backlog of sized stories and estimated story stubs. Teams doing this have more time to engage stakeholders on the definition of MVP, develop architecturally sound solutions, and work through dependencies.

Use a whiteboarding tool to brainstorm and document solutions

A picture is worth a thousand words, and collaborating with stakeholders on customer personas, journey mapping, and problem statements is a best practice. Teams must invest the time to develop a shared understanding of end-user goals and needs, but this isn’t easy when people can’t get into a room to brainstorm opportunities and solutions.  

Development teams should use better tools than vanilla whiteboards when brainstorming solutions with product owners and stakeholders. Two tools to consider are Miro and Creately; both offer numerous templates to get teams started with collaborative diagramming. Teams developing user interfaces should use wireframing tools such as Balsamiq, Moqups, Adobe XD, and other alternatives.

Development teams should also use diagramming tools to plan architecture and implementations. Three popular ones are Gliffy, Lucidchart, and Visio.

Invest time to learn, spike, and innovate with POCs

Innovation, learning, and experimenting shouldn’t stop because development teams work remotely. Perhaps the lunch and learns are less impactful for remote development teams, but there are options for remote teams to establish a cadence in learning, experimenting, and knowledge sharing. Here are some ideas:

  • Once a month, pick a public cloud service, have one development team conduct an agile POC, and then share the findings with other teams.
  • Look ahead at future features prioritized by the product owner and create spikes on the backlog to test new technologies or validate implementation options.
  • Research new learning opportunities, especially in agile and scrum, devops certifications, data science, or cloud certifications. When teammates take courses, enlist them to provide a virtual update to everyone on what they learned and how teams can apply those concepts.

The key for remote teams is not just the learning. Sharing with teammates and applying what’s learned is a great way for groups to stay connected as well as to reinforce an always-learning culture.

Get out of your comfort zone with low-code

Many times, remote development teams are called upon to deliver strategically important applications, integrations, and modernizations. But there are other times when the organization needs to roll out a capability very quickly, or the application requested will be used only for a short period of time, or the application requires complex workflows and integrations. When development teams feel like their plates are too full or that the application requested is outside of their development strengths, they should consider alternative options to develop and support applications.

One of those application options should include using a low-code platform. Low-code and citizen development platforms are important options for remote development teams who likely have a growing stack of application requests to digitize workflows and modernize legacy applications.

The best practice here is to get out of the developer’s comfort zone and the assumption that the best tool for the job is always coding. Developers are innovators, problem solvers, and artisans. Understanding different implementation options can lead to delivering new capabilities faster. 

Shift testing and security to the left

Regardless of how you develop applications and where you deploy them, development teams must test applications to ensure application releases meet functional requirements, performance standards, security requirements, and other compliance obligations. Remote development teams cannot rely on end-users to perform robust user acceptance testing. They will need to automate platform, API, functionality, performance, and security testing. Teams with CI/CD pipelines should consider continuous testing, where the pipeline triggers a subset of the automated tests.

Remote development teams also should feel a greater urgency to implement shift-left testing strategies, where robust testing is established and automated earlier in the development process. No one wants to deploy defects to production or respond to production incidents, but the barriers to fixing them (and the costs and stresses) can be significantly higher when many people work remotely.

Two other focus areas for remote development teams include shift-left security and using feature flags when introducing new capabilities. The best practice here is that remote development teams should focus more on improving the quality of deployments than increasing deployment frequencies. High-quality deployments are more important than speed.

Automate low-risk change management

The last thing remote development teams want is to spend hours in a change advisory board meeting to get approval for low-risk application deployments. This meeting may not be a great use of time, but the formality of the process is important for operational and security teams, who often trace production incidents back to these change approvals. Also, many companies must have a change approval process for SOC 2 compliance and other audits.

In tandem with operations and compliance leaders, development teams that have implemented CI/CD, continuous testing, and shift-left security practices should explore options to digitize or automate approvals for low-risk changes. Tools can help alleviate the change approval formalities, for example, by auto-approving standard changes in Jira Service Manager.

Develop an outside-in culture by seeking input from other developers

Development teams should also seek out other best practices. Here are some good examples:

  • Tiffany Jachja, a developer advocate at Harness, recommends maintaining a health-first mindset (e.g., flexible schedules, breaks, good ergonomics) and creating a culture that promotes digital sharing.
  • Semi Koen shares several work-from-home recommendations and suggests avoiding digital distractions and staying visible on collaboration tools.
  • Several developers provide recommendations for remote scrum standups, and Ekram Aktas recommends focusing on the obstacles and allowing “in the zone” developers to miss the meeting.
  • Lastly, if you have questions or concerns about remote development work, or you’re interested in getting a developer’s perspective on working remotely, then I recommend checking out Tom Cafferkey’s “10 myths I busted working remotely as a developer.”

Development teams who seek outside advice, opinions, and best practices can take advantage of other people’s ideas and solutions to overcome their remote working challenges. They may also gain insights into brainstorming, innovating, and solution building they can apply to the broader opportunities and challenges of the business.

Copyright © 2021 IDG Communications, Inc.

How to choose a low-code development platform