Response to the article: Sharing the knowledge – The role of communication across teams.

The following article is a response to the blog post: Sharing the knowledge – The role of communication across teams by Nick Kaltsas.

 

Introduction

In this post, the author described the importance of the communication and made the management of the cross team communication. When the project has a clear goal, enough experienced people and adequate resources, communication would become the determining factor in the large scale and long term projects. If projects benefit from the efficient communication and coordinating, it would boost the productivity, vice versa.

 

The importance of the communication

I agree with author’s view that communication is really significant in projects, especially in a single large project. This project cannot be independent and need organization to complete it. There are numerous relevant teams to address the problem together. If we ignore communication here, there will produce many drawbacks, such as functional defects and low quality buggy products. In the paper, the example of slow code illustrates that revising the problem result from lacking of communicating would be a waste of time. Author regards communication as a determined element to make or break the final projects in every large scale projects. It can promote the development of software depending on sharing knowledge and exchanging useful information.

 

However, I disagree that every team needs communication.  In some small teams, communications are carried out directly and regularly. They can learn from each other and solve the potential problems as early as possible. In the mean time, it will also lower the productivity of projects because of a waste of time in communicating. What’s more, when the team did not familiar with the project, they would ask two experienced people in charge of the same module so that we could compare the results to select the best one. According to this case, when the individual team organizes the team communication, it will stiff the creativity in this kind of module since they share their ideas.

 

Organizing cross team communication

Managing cross team communication needs to show many details of projects. Nevertheless, different teams often locate in different sites.  They cannot organize face to face communication all the time. When they use other informal communication (e.g. emails, video, conferencing), it would make a contribution to low confidence, delay, and communication failures. As author’s instance of Nokia and Microsoft, which minimize the need of the communication, there is another example to prove that communication cannot apply to every large scale and long term projects.

 

When a company divides a big software development project into many parts. Different parts are in the charge of different teams. The company gives every team a clear goal and standard documents of the module they are responsible for. The tasks need every module has its independent feature; it could be used in different situations and would not be affected by other modules. The only thing need to communicate is that how to connect all the modules. It should focus on the interface at the end of the project. In case of this, if different teams communicate a lot, it would lead to loss the ability of software module independence.

 

Communication in global software development

Global software development (GSD) is a unique case of distributed software development that the teams across national boundaries. Communication plays a dominant role in GSD teams, but most of them are informal communication. This project was cooperated by two companies: Radiante Corporation and Tekelec. During the time of completing the project, the process of coordination, communication and collaboration is key reasons of successfully developing software. However, this project relies heavy on communication, there are many elements from communication reduce the productivity.

 

Initially, there are numerous differences in culture and language. Communication between the two companies should focus more on requirements definition, negotiation and project management. When they cannot understand each other entirely, it would make the project fail. For example, “ Overlooking the development of the future “ can be explained as overseeing its development or forgetting its development. Also, remote sites multicultural communication would lead to time delays, and failure to understand and explain clearly the required system standard. It would cause conflicts of budget and schedule overruns. In the end, members of the project will lose trust of each other.

 

In order to remove the barriers of communication in different cultures and languages, managers come up with some methods to solve the cross cultural issues. Such as cultural liaisons, bridgehead teams, rotation of management. Although it could address the issues, in the meantime, it will decrease efficiency and take the risk of failing in this project.

 

Conclusion

Communication of large projects has an inherent advantage of sharing knowledge to improve the process of projects and addressing the potential issues earlier. It is essential that communication should play a critical role in many large projects. However, when it comes to creativity, the ability of independent, geographical, temporal, linguistic hurdles, we should consider the styles and situations of communication, which could boost the projects’ productivity. Communication cannot apply to every large project. We need to consider about the different environments and conditions of the project.

Reference

[1] Layman L, Williams L, Damian D, et al. Essential communication practices for Extreme Programming in a global software development team[J]. Information and software technology, 2006, 48(9): 781-794.

[2] Brooks Jr, Frederick P. The Mythical Man-Month, Anniversary Edition: Essays on Software Engineering. Pearson Education (1995): 73-83.

[3] Cusumano, Michael A. “How Microsoft makes large teams work like small teams.” Sloan Management Review 39 (1997): 9-20.

[4] Andres, Hayward P. “A comparison of face-to-face and virtual software development teams.” Team Performance Management 8.1/2 (2002): 39-48.

[5] Lindvall, Mikael, et al. “Agile software development in large organizations.” Computer 37.12 (2004): 26-34.