<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">

6 Ways to Run a Distributed Development Team Like a Well-Oiled Machine

Remote Work


A well-oiled scrum team should have daily scrum meetings with a clear sprint cycle tuned to a couple of weeks, but if your team isn't working that smoothly, there are some intermediate steps you can take to pull them up and get them on track.

In a previous job, I inherited a ragtag group of multiple development teams comprised of one to five members each. The teams were all from different third-party vendors and were located in California, Mexico, Canada, the Philippines, Pakistan, and India. Each team held a critical piece to developing an eCommerce website. There was very little overlap between the teams, placing me in the middle to coordinate the work and bring the elements together at the right time.

Challenges with the team ranged from multiple time zones to plan across, language barriers, cultural differences, and occasionally tech that didn't always work as well internationally as it did in the continental U.S. There were some soft skill issues that took a bit of focus and time to work through, but ultimately didn't stop progress.

The goal was to move these teams from irregular, low-value, high-risk releases to a group that was releasing solid, low-risk site enhancements on a weekly basis.  

Here are process challenges and the changes made within the teams: 

1. Clear regular communication was needed. Historically, the teams barely met and typically spoke via email with their previous lead. Here's what we changed:
    • We established a weekly cadence call with each team that included a review of the backlog. The teams talked through work in the backlog and asked questions until they understood the goal for the task.
    • As questions were answered, anything that affected the initial issue description was updated to reflect the new information. That information was kept in one location.
    • If more questions came up before the next meeting, Jira comments were used to discuss them. 


2. We established clear workflows in Jira. The team didn't always know issue status. There were too few statuses and they did not reflect the work.

    • Adding additional statuses helped reflect the actual workflow. The team added "Ready for Testing" and "Ready for Release," allowing team members to understand where work was in the process at any time on their own. 

3. The creation of a prioritized backlog. By establishing a backlog for each team's Kanban board, questions on what should be worked on next by the team were removed. Gone were the days of cherry-picking what might be fun or easy. Instead, work on the key issues identified by the business took center stage.


4. Bitbucket was not fully integrated with the Jira instance, and the team's GIT branches were not clearly related to the Jira issues work, making the release process slow and error prone.  

    • The teams were guided in prefixing their GIT branches with the Jira ticket. Also, a comment on the Jira ticket with the Commit ID provided full traceability back. I would recommend linking Bitbucket to automate this work.

5. History on how a system was set up and how it integrated with other system was often a mystery. Confluence was engaged by the team to begin capturing the base configurations, as well as changes in the following versions of the code. 

    • Linking Confluence documentation to a feature issue saved hours of time spent on calls reviewing how a system worked. This allowed the teams to work more efficiently and maintain the documents for future use.

6. With a tight budget, the need to understand costs for development was key. It was established that issues could not be approved to start until an estimate was provided. Previously, the team would email lists of issue numbers and estimates back and forth, negotiating for approval.

    • Having teams enter time onto the Jira task and an explanation of where the time was needed helped get quick approval for work on the issues.


Working with distributed teams can be challenging, and Atlassian tools can help ease the challenge. Hopefully, something in the above list of changes that helped me turn my teams around can help you improve processes with yours.   

Atlassian Solution Partner

TAGS: Remote Work

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Subscribe to Our Newsletter

Recent Blog Posts