Run an Agile Development Process with a Distributed Engineering Team

Tech companies are always looking for ways to do things faster, better, and smarter. At Upwork, we’ve found that creating distributed teams—a hybrid mix of onsite and remote engineers—enables us to scale up and make software development lean and affordable.

In this article, we’ll share a bit about how adopting an Agile culture has helped these teams increase productivity and collaboration—including our take on meetings, code review, testing and deployment. (Note: We’ll assume you have a basic understanding of the Agile methodology and scrum, but if not, we recommend reading The Art of Agile Development by James Shore and Shane Warden.)

Syncing Up with Team Meetings

At Upwork, getting things done the Agile way revolves around a series of highly productive meetings that happen daily, weekly, and biweekly, after each two-week sprint. Because Agile by its very nature keeps dedicated teams fairly independent from one another, we rely on these meetings to sync back up.

Whether they’re attending in-person, virtually, or a mix of both, members of our distributed engineering team participate in:

  • Daily standups: Quick 15-minute get-togethers cover what each team member did yesterday, is doing today, plans to do tomorrow, plus any roadblocks encountered along the way. We schedule standups at a time that allows for at least four hours of aligned availability afterwards to tackle any issues that were raised.
  • Backlog grooming: During this collaborative meeting, new, prioritized projects coming out of the backlog are handed over to the team and broken into tasks, and it’s estimated how long it will take to get each done. Grooming sessions are excellent team-building opportunities and result in actionable plans for the next sprint.
  • End-of-sprint demos: Developers can share what they’ve built during the sprint with product owners and any other invested parties. We use Google Hangouts’ screen-sharing capabilities so everyone can follow along, no matter where they’re located.

Code reviews and cross-team collaboration

To ensure our distributed teams had a way to easily access shared code in an organized way, we moved from Git to Bitbucket (Atlassian’s augmented version of Git) because we found it offered a few key benefits. First, its excellent code review tool allows our product architects to review code when a developer is offline. With team members in different time zones, this enables us to “chase the sun,” reviewing code and keeping a project moving even if its author is sleeping in another part of the world. Pull requests allow for cross-team collaboration, and tight integration with JIRA, a tool we use for tasking, help us speed up turnaround.


With version control handled, we wanted to optimize our resources when it came time to test the batches of code we regularly crank out in two-week sprints. We moved from a long cycle of manual testing to a mostly automated testing infrastructure. This makes us able to complete a full suite of unit testing in one hour, and a full suite of parallelized functional tests in about six hours.

While we still have a dedicated QA team, we’ve progressively moved our test engineers over to an Agile environment where they work on dedicated teams. It’s allowed them to work more closely with developers, dramatically changing our engineering culture: There’s less throwing code over the fence for QA to clean up. Instead, developers own the quality of their code, and test engineers are on hand to build the automated tests they need.


Because each Agile team is likely to be working on a single branch of code not shared by another team, we encourage teams to rebase frequently and merge back to the main branch at least once a week to avoid surprises. With two-week Agile sprints, we’re routinely deploying big features in small batches. To reduce release risks, we’ve taken certain measures like building our own library with flags to expose merged code to only alpha/internal users. Also, our staging environment is setup so that the distributed team can get feedback on what broke the build.

Putting Agile Culture into Practice

This is only a quick intro to how we’ve changed the way we get work done at Upwork. If you’re ready to shift into high gear and start applying these and other learnings to your own process, download our eBook for a more in-depth look at the process, tools and best practices used by Upwork and other companies like Automattic, and Trillimar Webcraft, download the free Hire Fast & Build Things eBook and check out “Distributed IQ: Development Process.”