1. Foster a culture of continuous integration when builds are constantly discussed and planned.

Creating a culture where continuous integration is the norm is especially valuable on projects with extended timelines or when managing remote teams. In this structure, it’s easy to opt for dividing work for teams along technical boundaries. These technical boundaries may be divided by frontend/backend work or even database and services layer/frontend. Team bandwidth or security might drive the divisions. Additionally, some businesses may be wary of releasing intellectual property into a cloud-based platform like GitLab.

This often results in the maintenance of two source code repositories with a commitment to merge them later. Resist this. The technical debt that results from this fractured code is more time-consuming to overcome than if the teams had increased the communication necessary to maintain just one code repository in the first place. Overcoming any communication hurdles to work on the same code base is worth it in every way.

Team leads successful at managing remote teams and implementing this culture will even begin to see evidence manifest in the daily communication and behavior of team members:

All members actively strive not to break the build.
They will provide visibility to broken builds.
All will react with a sense of urgency to adjust build issues.

2. Commit to regular builds, so you don’t prioritize upholding the plan over agility.

It’s easy to produce a giant spec in lieu of communicating daily with the offshore development team or let distance become a reason to stay the course and avoid evolving the solution when challenges or barriers arise.

Building on a weekly schedule is good, daily is even better. Hold your team accountable to submit a change set to the source code control each time. Then, take advantage of your compiler as a stand-in team member to ensure your source code has reached or exceeded quality expectations. Adding smoke tests can move this dial even further.

3. Embrace the social process of developing custom software.

Most people assume custom software development is a purely technical process. While it’s true the process is highly technical requiring years of training and experience to run successfully, software development is a social process first and relies on trust built between individuals.

Encourage knowledge sharing on every team. This is less about cataloging processes in a Wiki and more about cultivating this naturally in daily stand-ups or any time team members give updates.

Encourage your team to share beyond what pertains to that day’s work. If a team member anticipates something they are working on may impact another role the next day, call that out. Once team members master the habit of sharing meaningful, forward-looking insights to their work, that’s when true knowledge sharing has been achieved.

<aside> 🗣️ Get the eBook: The Complete Guide to Organizing and Leading Distributed Teams

</aside>

4. Foster close communication between UX designers and business analysts to accelerate throughput by a factor of two.