Osmotic Communications

Home The Savvy PM Blog Osmotic Communications

141 As the PMI Agile popularity continues to grow, I thought it would be fun to address some Agile terms. I’m starting with “Osmotic Communications.”

First a minor point on vocabulary: communication is difficult enough on its own, but I believe the term should probably be “Diffusive Communications” since in diffusion, particles move about randomly from areas of higher concentration to areas of lower concentration. In osmosis, particles may move from areas of lower concentration to areas of higher concentration through the help of a semi-permeable membrane.

Diffusion explains why the whole ocean is salty. Osmosis explains why you retain water when you eat salt. Perhaps osmotic communication would be the preferable term if the semi-permeable membrane were your skull. That said, let’s talk about osmotic communications (and you can think about diffusion if that helps you understand it).

Suppose a user has detected an issue with a feature that is under development and decides to approach a programmer to discuss it. In a traditional siloed environment the user would seek out the project manager, and the PM would then identify the right programmer and bring the issue to him or her. The problem is that the rest of the team is probably left in the dark about the issue, the implications, and the plan to correct it. They may get informed at a future meeting, but information will probably flow on a need to know basis. After all helping them to focus is good – right?

But in an Agile environment this would probably look very different. The user might approach the program team directly, walking into the war room during hours designated for this kind of thing. The user could then quickly identify the programmer with the most knowledge about this feature and can discuss how to correct it. The real beauty of this is that the rest of the team can passively listen in to (or tune out) the discussion. They may find that the issue really requires a broader fix, or they may already have something that will address it. They are informed and can participate without having to spend time on extensive documentation, meetings, or formal updates. By having the team co-located and by having all of the communication out in the open, a greater overall participation and awareness emerges.

I had a situation some years ago that illustrated the power of osmotic communications. A user came to me with a problem; the Windows cursor was mysteriously blinking from an hourglass to an arrow while processing was taking place. The user and I both assumed this was caused by a module I had written the previous week, but before I could say a word, another programmer in the room with me said “it’s me. I’ll have a fix later today.” He never even looked up from his screen, but he saved me hours of trying to trace through the code and track down the problem.

Communication is the lifeblood of any successful Agile project, and osmotic communications make certain that the whole team maintains a useful level of awareness about issues and developments with a minimal amount of overhead, and formality.