Alexey Krasnoriadtsev has 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, he shares with us his approach he's adopted to overcome the communication, process, and quality assurance obstacles facing team members who are a date line and time zone away.
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.
When everyone knows the project vision and no one engineer has a single area of responsibility, the work that the team needs to achieve becomes visible across multiple sites. Plus, with working software as the primary measure of progress and every team member scored on the code and the code reviews he or she does, team members become more self-motivated and quality becomes a team-wide responsibility.
Concentrate on Test Automation
AgileFusion specializes in mobile application development, so for our purposes, the feature must be fast and responsive in order to ensure good usability and end-user satisfaction. In a manual testing scenario, a tester writes the test cases, tests them, and gives his feedback to the developer. While this is taking place, developers have already made numerous changes to the code. When you consider many developers making 24/7 changes to code in a distributed environment, the feedback received from the tester is immediately outdated and faulty. With test automation, once a test case is written it can be executed and the application can be tested again and again as soon as any change in the code occurs.
Automated testing gives our teams fast, reliable feedback when making changes—something you just can’t do manually, especially when working with distributed teams. Automating the most important end-to-end use cases is the top priority. Those cases that continuously test the critical features of the app, such as finding and purchasing a product, opening a book, and finding or adding a new contact, would guarantee that such cases continue to operate and are never missed or overlooked.
Test automation metrics also help our teams set goals and measure progress. Most successful test organizations track and publish test automation metrics, which inspire pride and competition among their teams. These build metrics are important because these reports help our teams to pinpoint the issues that don't break the products but slow down the performance.
Finding the root causes of performance at the end of the project can be very time-consuming. Our reports help us to quickly identify the build where the issue first surfaced and the code that introduced the performance degradation.
Conclusion
Applying agile techniques to distributed development does work, but it requires more than simply adopting a particular framework or process. To be successful, you must create an inclusive environment where all team members are proactive, fully understand the big picture, and are dedicated to the success of the entire project, not just their particular piece of code.
Effective communication is key to making this happen. Leveraging blends of technologies for teams to communicate and share information establishes trust. The result is a more effective team, regardless of where they are located.
Communication and trust also allow you to eliminate silos of ownership. Quality and efficiency are greatly improved when every member of the team understands the big picture and is expected to contribute to every aspect of the code and engineers are measured on both fixes and code reviews.
Finally, automated testing is crucial in an environment where development is taking place 24/7. It not only acts as a safety net against new development, but more importantly, it also frees up a lot of precious developer and tester time—allowing them to focus on the things they do best.
