Thursday, April 30, 2009

Sharing information within organizations

Naresh Jain tweeted code reuse being still an unsolved problem within organizations some days ago. This made me think that this is a symptom of a more general problem within organizations, who do not account for information and knowledge transfer costs.

I’ve seen a few attempt to promote reuse within organizations, and they all failed because they assumed a non realistic communication model within the organization. In some cases the approach was completely naive: just because some code had been written to address a specific problem, everybody was supposed to know about this code. There's only one organization capable to achieve such level of coordination: it's called "
The Borg". They have a collective intelligent and are continuously in sync, one and another.
This type of information sharing simply does not happen in nature.

A more sophisticated approach involved use of repositories and/or knowledge management system to promote information sharing in a common tool. I've seen most of these approach fail as well. Having a common repository to share the information is generally a good idea, but expectations on those systems were really high, and probably unreasonable.

The starting point to promote code reuse within an organization is to know that there is some code that already solves your problem. From a communication perspective we have Developer A, a potential
writer of an information at time T0 who knows something about what he's currently doing. Some times later, or maybe simply somewhere else, we'll have Developer B with a similar problem, at time T1. To have a successful communication:
  • A should have written something meaningful about the problem he solved
  • B should have searched the repository for an existing solution
  • B should have found what A wrote
  • B should have recognized that what A said was relevant to his problem
I think most of these steps are inherently non-trivial, basically because there is a huge amount of arbitrary decisions in every step (including whether to do the step or not). Words used by A might be different from words used by B to search. Or the information might be filed under an arbitrary label. Basically, this is a decoupled asynchronous communication. There's no feedback possible, and every arbitrary decision is an obstacle between A and B.

I personally find structured systems for storing information particularly bad: they
force users to choose where to file their data, and the way people label their knowledge varies a lot form person to person and from time to time. Non-structured information repositories, such as Wikis with a Google-like search tool are definitely better, but they don't solve the core of the problem.

Sometimes we can connect our specific problem to a more general case, for example a "shortest path problem" or a "traveling salesman". This is probably how we'd call the problem after we've found the solution. The way we describe the problem before might be a lot different. Knowing how to call the problem is already a step towards the solution. This means also that who describes the problem and who describes the solution might use different terms. making our asynchronous-remote-decoupled communication at high risk of being completely ineffective.

Effective communication about partially unknown problems needs a higher amount of feedback. That's what we do when reading the menu in an ethnic restaurant: or (closer to our example) when we get into a shop to buy things we've seen but we don't know the name. A clerk might have a gotcha and tell us "Ah! you meant this!" showing us what we wanted and telling us how it's called. The most effective way to communicate about unknown things is the one with more feedback: face to face conversation.

Unsurprisingly, organizations trying to push communication through structured systems are often the ones that put a lot of efforts in preventing effective face to face communications to happen. Well ... in fact
preventing good things to happen is one thing organizations are good at. And effective communication is one of these fragile things which might happen in a good environment, but there's no way to force them to happen.

Thursday, April 16, 2009

The Big Agile Practices Survey

Jurgen Appelo is is currently doing an interesting all-round survey about agile practices. The more people will participate, the more accurate the results. If anyone is interested, just follow the link.
Blogged with the Flock Browser

Wednesday, April 15, 2009

Kanban vs Scrum

Thanks to Jurgen Appelo, I've found this incredibly clear and useful article about Scrum and Kanban on Henrik Kniberg's blog.
The type of reading that makes things perfectly clear. :-)

Blogged with the Flock Browser

Wednesday, April 01, 2009