Mark Needham

Thoughts on Software Development

While in India: Osmotic communication

with 2 comments

One of the things that has been puzzling me during my time in India is the amount of time that is spent in meetings pushing information to people rather than them pulling it.

In previous projects that I’ve worked on a lot of the knowledge was moved between around as a result of osmotic communication

Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis.

This is normally accomplished by seating them in the same room.

Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work.

After thinking about it a bit more I’ve identified a few reasons why I think this approach doesn’t work so well on my current project.

The ability to ignore background noise

The ThoughtWorks Pune office is pretty much one big room with over 100 people in it so the amount of background noise is fairly constant.

When we’ve tried to run our standup near where we sit it’s been impossible to hear people standing 5 or 6 metres away from you.

You therefore end up getting into the habit of blocking out anything going on around you as was evident when there was drilling being done in the office.

The side effect of doing this, of course, is that there could be relevant discussions going on around you and you’d be much less likely to notice.

Team size/distribution

The second problem is that the team is distributed which means that we’re never going to overhear any conversations in Chicago and vice versa.

To add to this our team is now 25+ in size so it’s spread out over 3 tables one of which is only within shouting distance.

Martin Fowler wrote an article about team rooms quite recently and while the ideas make sense I’m not sure how they scale as team size increases.

Overlap of roles

Although this by no means applies to everyone that I’ve worked with I’ve noticed a tendency for people to stick to their role much more than I have in other countries.

Therefore a developer will only do ‘developer tasks’ and a QA will only do ‘QA tasks’ for example.

When you have overlap such that a developer may be ‘pairing’ with a QA or BA on something then the types of conversations that are head seem to lead to information moving around the team more effectively.

Be Sociable, Share!

Written by Mark Needham

January 24th, 2011 at 3:33 am

Posted in Communication

Tagged with

  • Pingback: Tweets that mention While in India: Osmotic communication at Mark Needham --

  • Let’s see, I’m going to have to discuss these in pieces; about…

    * Background noise: I remember back on the project I shared with @nigelfds and Sriram Narayan ( we cherished a lot of the ‘serendipitous communication’ (Sriram has dibs on that term) that went around the table. In fact, we relied on it. But I think the next point was an important factor in this being successful.

    * Team size/distribution: I agree, the serendipity afforded by sitting at the same table doesn’t scale across tables. We were luck to be just under one-table-strong. That way we were always less than an earshot from every team member.

    * Overlap of roles: Can’t agree with you more here. That’s a trait we definitely need to encourage.