You can’t deny the benefits of agile. The mainstream approach has helped countless companies increase flexibility within their organizations and thus develop better, more intuitive software. Distributed development is also a vital approach for software organizations. It allows access to global talent, permits leveraging offshore outsourcing to reduce costs, and enables round-the-clock development.
Enlisting distributed development teams that follow agile principles can create a huge competitive advantage. However, face-to-face communication, frequent customer conversations, and collaborating team members are fundamental tenets of agile. So, how do you apply agile techniques when team members are not sitting next to each other?
I’ve been managing globally distributed projects for more than ten years, applying agile methods to improve process efficiency, increase team productivity, and deliver quality products to market faster. With teams split across the globe, here is the approach I’ve adopted to overcome the communication, process, and quality assurance obstacles facing team members who are a date line and time zone away.
Facilitate Continuous Communication
At AgileFusion, our typical team size is between fifteen and twenty-five members across the United States, Russia, and Thailand. This includes six to twelve engineers, three to six QA engineers, a product manager, at least one designer, and, of course, the customer.
I like to conduct a full-team conference call with all team members involved to kick off a project. This ensures everyone hears the same message, understands the goals, and allows you to lay the foundation for how the teams will work together. Afterward, we employ a number of communication tools such as video conferencing, wikis, email, message boards, code comments, and code reviews, depending on the need. This approximates face-to-face contact in terms of effectiveness, and we combine methods based on what needs to be conveyed across team members.
While texts, instant messaging, and video conferencing are well-suited for on-the-fly, one-to-one communication in real time—a basic fundamental of agile principles—another effective communication tool is code. Having a daily build or continuous build of code communicates volumes about the state of the project, and it allows all team members and stakeholders to see current code and comment about it. It also ensures everyone is working on the same thing—the shared build.
Communicating with code also facilitates additional forms of communication to ensure your team stays in sync, including instructions about standards, documentation, and test coverage; voting and consensus-building around feature and architecture questions; and discussion among stakeholders about contributions accepted and deployed in the shared build.
Disagreements during the development process are going to happen. Overcoming these in a distributed environment, where team members may speak different languages or have cultural disparities, can be challenging. I require my teams to propose a solution to any problem or disagreement, which the team leader can then evaluate to make a final decision. Another effective way to minimize disagreements is to eliminate ownership silos.
Eliminate Ownership Silos
With distributed teams, it's essential for members to unite around a common purpose. Everyone must agree to the team's goals and understand the vision of the software project. This is what helps engineers appreciate what they do and do it better to make a positive impact on the end product.
The best way to accomplish this is to remove “silos of ownership,” where developers are only responsible for their specific part of the application. At AgileFusion, every developer owns the whole product and is expected to contribute to every aspect of the code and review check-ins from every part of the code. This minimizes the “mine-versus-not-mine” politics that can often arise and promotes cross-training and knowledge-sharing of the code by all team members. It also ensures consistency in code formatting, style, naming conventions, etc.