You may take these three ideas from Scrum that may be useful to you.

1. Scrum of Scrums - a regular meeting of team representatives (usually one per team). In Scrum, the point is to communicate and resolve team level problems and blockers together. So the meeting is focussed (although not as strictly as the daily calls) to avoid wasting time. But you may adopt it to your needs.
2. Product demos - whenever a team completed an important milestone or new feature, arrange a public demo and invite other teams as well.
3. Communities of practice - these involve subject matter experts across teams. I.e. you may create a CoP for testers, another one for statisticians etc. These may run own mailing lists, organize more or less regular events like brown bag sessions, pub nights etc.

As David Espina points out, communication has its cost so it should be kept under control. However, not all communication can be planned in advance based on project needs; we don't always know what we don't know! So one should leave some room for unplanned ad hoc, free form discussions as well. The question is of course, how much that some should be; too little is as dangerous as too much. The needs and ways should be tuned individually for each team / organization via inspect and adapt cycles.

To show the other side of the coin, insuffficient communication may also lead to problems in the long run, including:

• duplicated features, reinventing the wheel again and again
• misunderstandings, which may even result in costly project failures
• "us versus them" type of conflicts between persons / teams, resulting in burnout or high turnover as well as project problems

You may take these three ideas from Scrum that may be useful to you.

1. Scrum of Scrums - a regular meeting of team representatives (usually one per team). In Scrum, the point is to communicate and resolve team level problems and blockers together. So the meeting is focussed (although not as strictly as the daily calls) to avoid wasting time. But you may adopt it to your needs.
2. Product demos - whenever a team completed an important milestone or new feature, arrange a public demo and invite other teams as well.
3. Communities of practice - these involve subject matter experts across teams. I.e. you may create a CoP for testers, another one for statisticians etc. These may run own mailing lists, organize more or less regular events like brown bag sessions, pub nights etc.

As David Espina points out, communication has its cost so it should be kept under control. However, not all communication can be planned in advance based on project needs; we don't always know what we don't know! So one should leave some room for unplanned ad hoc, free form discussions as well. The question is of course, how much that some should be; too little is as dangerous as too much. The needs and ways should be tuned individually for each team / organization via inspect and adapt cycles.

To show the other side of the coin, insuffficient communication may also lead to problems in the long run, including:

• duplicated features, reinventing the wheel again and again
• misunderstandings, which may even result in costly project failures
• "us versus them" type of conflicts between persons / teams, resulting in burnout or high turnover as well as project problems

You may take these three ideas from Scrum that may be useful to you.

1. Scrum of Scrums - a regular meeting of team representatives (usually one per team). In Scrum, the point is to communicate and resolve team level problems and blockers together. So the meeting is focussed (although not as strictly as the daily calls) to avoid wasting time. But you may adopt it to your needs.
2. Product demos - whenever a team completed an important milestone or new feature, arrange a public demo and invite other teams as well.
3. Communities of practice - these involve subject matter experts across teams. I.e. you may create a CoP for testers, another one for statisticians etc. These may run own mailing lists, organize more or less regular events like brown bag sessions, pub nights etc.

You may take these three ideas from Scrum that may be useful to you.

1. Scrum of Scrums - a regular meeting of team representatives (usually one per team). In Scrum, the point is to communicate and resolve team level problems and blockers together. So the meeting is focussed (although not as strictly as the daily calls) to avoid wasting time. But you may adopt it to your needs.
2. Product demos - whenever a team completed an important milestone or new feature, arrange a public demo and invite other teams as well.
3. Communities of practice - these involve subject matter experts across teams. I.e. you may create a CoP for testers, another one for statisticians etc. These may run own mailing lists, organize more or less regular events like brown bag sessions, pub nights etc.

As David Espina points out, communication has its cost so it should be kept under control. However, not all communication can be planned in advance based on project needs; we don't always know what we don't know! So one should leave some room for unplanned ad hoc, free form discussions as well. The question is of course, how much that some should be; too little is as dangerous as too much. The needs and ways should be tuned individually for each team / organization via inspect and adapt cycles.

To show the other side of the coin, insuffficient communication may also lead to problems in the long run, including:

• duplicated features, reinventing the wheel again and again
• misunderstandings, which may even result in costly project failures
• "us versus them" type of conflicts between persons / teams, resulting in burnout or high turnover as well as project problems