An easy to overlook part of coordinating a large scale project is communication across teams. While it is trivial to ask from people to write some documentation and organize technical meetings, there is a lot more to exploiting the benefits of good communication or avoiding the negative effects of bad communication.. As it is noted by Frederick P. Brooks in [1], while a project may have a clear goal, enough people with suitable experience, knowledge and sufficient resources it may easily fail if communication fails. Communication, and subsequently coordination, across and within teams is a determining factor in large scale projects that can significantly boost [6] or hinder productivity. To investigate the matter we will discuss how teams and processes must be organized to exploit the benefits of communication and avoid the risks associated with the lack of it.
Is communication really that important?
Tasks on a single large project are rarely completely independent and there is need for organization such that efficient communication takes place across relevant teams. Functional defects, low quality buggy products, inability to follow the schedule might all be the result of development teams being unaware of the work done by fellow teams. For example, consider a piece of code that isn’t designed to be fast because is rarely used by the system. A team may choose to use it, as it would fit well for a new feature it is developing, and will in return sacrifice a lot of valuable time trying to figure out why their code isn’t working as intended. In other cases such things may go unnoticed and buggy products may surface. Thin spread of domain knowledge, fluctuating and conflicting requirements are also likely to cause problems. All this means time, money, and quality will be wasted unless there is sufficient care in designing a development process with communication in mind.
On the other hand, it is not only that the lack of communication causes problems, there are also significant benefits to be found in sharing knowledge among teams. Hayward A. suggests in [3] that success in software development is dependent upon knowledge acquisition, information sharing & integration and minimization of communication breakdowns. The first two factors imply that sharing and usage of knowledge acquired by different teams can be key to increasing productivity. In small teams, where group members communicate directly and regularly, this is easy to achieve and it has been proven [2, 7] that productivity and confidence is much higher in these teams rather than in large development teams. In small teams knowledge and ideas spread effortlessly allowing for flexibility, efficient coordination and autonomy. The differentiating factor between small teams of a few people and big teams of hundreds of developers is the communication, or lack of, amongst the members.
Modern organizations that work on large scale products have realized the importance of communication and divide development teams into small agile groups that work on distinct tasks. However, this is not enough. Communication within teams may be excellent but there is still a need to dictate communication and dependencies across different teams.
So how should cross-team communication be managed?
There is no single best way to deal with this issue. Thus, lets start by stating the basic prerequisite methods that have to used in any software development project. Firstly, documentation and code comments should always exist as they are the simplest form of communication. A coding style that is standardised across all development teams and the usage of common tools is another factor that will help make code more readable and easy to modify. Additionally, the concept of interval builds (daily, weekly or similar) introduces the early detection of problems and is a way of encouraging teams to communicate and find the cause of them. Communication both formal (regular meetings, technical briefings) and informal (telephone calls, discussion outside meetings) must be encouraged to make sure that implementation details, decisions, and changes are quickly communicated across relevant teams.
While all the above are important and should be taken care of, the actual way teams are created, assigned and located is the determining factor in order to exploit the benefits offered by efficient communication. It is clear that teams should be as small as possible, since small groups work more efficiently. But since there will always be dependencies across teams, how does their location matter? Andres Hayward concludes in his study at [3] that face to face communication is such a rich form of interaction that teams collaborating through face to face meetings might have as much as double the productivity in comparison to teams that interact without social presence (emails, video conferencing). The latter form of communication was also found to result in low confidence, delays, and communication failures. Moreover, in [5] and [8] it is agreed that no matter the multiple ways that exist for communication of teams that are geographically distributed and even if ideal conditions are considered, the levels of coordination, communication and productivity achievable can never match those offered by teams working on a single site. All this shows how important it is not only to have regular meetings and briefings but also how important it is to have all teams working in a project under the same roof. Bill Gates himself [2] realised the importance of being able to go and find the person who wrote the piece of code you have a problem with and made sure that each of his projects is developed on a single site. Even in cases when this is not possible, teams should be divided to sites in a such a way that the sub-projects of each site are largely independent and use rotation of the teams when dependencies change.
Another approach successfully used by large companies, such as Nokia , described in [4], is to minimize the need for communication across different teams. The idea here is that since small teams have proven to be very productive, especially when working autonomously, dividing a given project to tasks in a way that eliminates dependencies across different teams will minimize the communication overhead. Microsoft is also known to use such techniques, where in [2] it is stated that teams are assigned to features that mirror the structure of the product and are as independent as possible. Of course, it is recognised that communication is needed to share and integrate knowledge and that there will always exist tasks whose completion is dependent on more than a single team. The method Nokia uses [7] to address these facts is very interesting. To make sure that newly acquired knowledge can be exploited by all teams and that issues affecting multiple teams are efficiently solved, cross-team workshops are organised regularly. In these events, people from different teams are gathered to work on specific tasks or solve issues that affect the work of multiple teams. These methods of work, while they may not be applicable to all kinds of software projects, have been found, in practice, to increase both overall productivity and individual team performance.
What is the lesson to be learned here?
To conclude, it should be apparent that the coordination of teams, their interrelationships and the means of communication between them are critical to efficient large scale software development. It can be the single factor that makes or breaks the final product. In practice, the majority of the methods described here could -and should- be combined and applied in any large scale project.
References
[1] Brooks Jr, Frederick P. The Mythical Man-Month, Anniversary Edition: Essays on Software Engineering. Pearson Education (1995): 73-83.
[2] Cusumano, Michael A. “How Microsoft makes large teams work like small teams.” Sloan Management Review 39 (1997): 9-20.
[3] Andres, Hayward P. “A comparison of face-to-face and virtual software development teams.” Team Performance Management 8.1/2 (2002): 39-48.
[4] Lindvall, Mikael, et al. “Agile software development in large organizations.” Computer 37.12 (2004): 26-34.
[5] Espinosa, J. Alberto, et al. “Team knowledge and coordination in geographically distributed software development.” Journal of Management Information Systems 24.1 (2007): 135-169.
[6] Hoegl, Martin, and Hans Georg Gemuenden. “Teamwork quality and the success of innovative projects: A theoretical concept and empirical evidence.” Organization science 12.4 (2001): 435-449.
[7] Kahkonen, Tuomo. “Agile methods for large organizations-building communities of practice.” Agile Development Conference, 2004. IEEE, 2004.
[8] Grinter, Rebecca E., James D. Herbsleb, and Dewayne E. Perry. “The geography of coordination: dealing with distance in R&D work.” Proceedings of the international ACM SIGGROUP conference on Supporting group work. ACM, 1999.