Delivery of a high-quality product and its evolution in the course of releases requires collaboration of several project roles represented by teams of people: the Customer team works on the continuously evolving product requirements, the QA team ensures the solution works as designed, while the development teams do the heavy lifting to actually bring the product to life. The whole mechanism shall run like clockwork to deliver up to par.
But in the world dominated by outsourcing models, all of these teams are rarely located at the same whereabouts, forming functional and structural project silos. Different backgrounds and time zone differences add to the difficulty of communication and knowledge sharing among team members. Let’s look at the five fundamental practices to boost essentially the efficiency of communication in large, geographically distributed project teams:
When teams are geographically dispersed, some (or even all) of team members have to be flexible enough to shift their working hours to attend daily voice/video calls. However, such meetings shall be timeboxed to 30 minutes, with the time limit never exceeded without a good reason.
Hosted by the team lead, the meeting sets scene for all team members to report on the status of the tasks previously assigned to them. The team lead assigns and prioritizes the tasks due to completion within the current iteration, while developers discuss issues on the current tickets. Occasionally, project managers shall join these meetings to update the team on the upcoming product versions, project direction and delivery process adjustments.
Publish short meeting follow-up reports in the team blog. Indicate the tasks that are completed, and add notes to the recently created ones. Team blogs are instrumental in providing project managers with a 360-degree view on the status of all current tasks.
Usage of proven design patterns and any other software development best practices provide for a consistently high product quality even under requirements volatility. A project Book Club is the collection of books, articles and any other resources that are useful for the current project activities. Being a single source of information on all templates, approaches and styles used on the project, it facilitates seamless knowledge transfer to new team members. The project Book Club can also be a reliable reference for team meeting reports or project documentation.
Enable all team members to share their thoughts and leave recommendations on the educational materials they study on their own. This will enhance significantly the overall level of team competency.
A Spike page is a task aimed at investigating into issues rather than producing a shippable product. But it’s a powerful tool to let individual developers bring the problems they run into to the collaborative consideration. This helps replace isolated problem shooting with systematic solutions as the project complexity grows and detect dead-ends at early stages. A spike page starts with stating the problem and contains all facts and assumptions considered. Experts can take time to sleep on it and propose the solution during one of the subsequent scheduled Spike reviews.
In the long run, Spike pages help other teams grasp the system design principles, mainly, why certain design decisions were made and how the system is going to evolve in the future.
Peer code review practices enable developers to not only timely detect and correct defects in the source code, but also help one another learn by inspection. When reviewing peer codebases, a developer gets to know solutions, classes or system enhancements that are new to them, and can evaluate their own coding decisions and adjust them accordingly. All in all, peer code reviews help ensure code consistency even when the whole parts of the codebase are rewritten.
Blogging helps to learn to communicate one’s thoughts clearly. Modern team collaboration software enables developers to create blog posts available to other team members within their personal spaces. When running into a particularly tough issue (or spike), a developer can describe it in their personal blog to solicit comments from other team members. Chances are, some of them have dealt with the same issue and have a tried-and-tested solution to it. Moreover, sometimes taking time to articulate the problem helps the person to eventually come to the solution all by him- or herself.
Daily reports contain feature implementation histories that may be useful for other teams as well as for the project managers who can refer to these reports when planning new iterations.