Pages: pp. 5-7
I once heard a well-known software development guru define insanity as "doing the same exact thing over and over and expecting different results." I'm not convinced this is truly the definition of "insanity," but it certainly fits the term "clueless." Obviously, the entire point of this guru's "definition" was to point out that when someone isn't learning from their mistakes, they can't expect things to improve.
If an organization fails to learn from its experiences, no matter how successful it might be initially, we can expect its performance to eventually decline to a point where the organization is no longer viable. History is littered with companies that were once the favorites of Wall Street but failed to effectively change and adapt, gradually sinking into obscurity.
On the other hand, a learning organization is continually increasing its capacity to produce results. Most software development organizations strive to become learning organizations, but far too few are successful. Why is this so rare? With some reflection, it's easy to identify a three-step process any learning organization must master. First, the organization learns something; second, it manages this knowledge; and finally, organizational behavior is somehow changed by virtue of this new knowledge.
To "learn something," the organization must be able to recognize its and others' mistakes and successes. The organization's eyes and ears are its people. When someone in the organization recognizes a mistake or a success, be it internal or external, he or she must be willing and able to make note of it. However, recognizing mistakes and successes isn't free. It takes time to reflect on what went right and what went wrong. It takes real effort to abstract an event's key issues so that they're applicable elsewhere.
When the successes are from outside the organization, it's even more difficult and time consuming to keep on top of things. Whereas much of what we know about our organization comes from either our direct experience or that of someone we trust and respect, other organizations' experiences almost always come from someone we don't know. They might appear in a journal article or workshop presentation or be relayed by a consultant. Some suspicion toward the messenger and the message is natural.
Academic software engineering researchers are one of the few groups of people actually paid to package, evaluate, and distribute the experience of software development organizations. But this doesn't necessarily mean they're trusted by one and all. The burden of proof required from a stranger is much higher than what we expect from a colleague.
Managing knowledge requires a mechanism for storing and distributing the experiences people capture. Human memory is a fleeting thing. Expecting someone to remember the details of an experience months later is unreasonable. Expecting that person to always be physically present at a time and place where knowledge of this experience is needed is downright delusional. There needs to be a corporate memory that can manage the knowledge contributed by the organization's people.
This must be proactive as well as selective. Expecting workers to poll colleagues for their knowledge—especially in geographically diverse organizations—is unrealistic. However, a constant stream of irrelevant (to the recipient) pieces of knowledge will just about ensure that the relevant knowledge will be missed. Like many things in life, there's a fine balance between too much and too little.
Fortunately, this can be the most straightforward aspect of being a learning organization because it lends itself to a technical solution. For example, the US National Aeronautics and Space Administration has an extensive Lessons Learned Repository at http://llis.nasa.gov/llis/plls/index.html. This is a good example of how an organization might choose to disseminate its people's knowledge.
Even with the first two ingredients, if the organization fails to change and adapt in response, there will be little if any benefit. People must be both willing and empowered to embrace this new knowledge and change their behavior based on it. It does no good to tell workers that a procedure was a great success when someone else carried it out in a certain way if they are forbidden from changing how they do the procedure. Likewise, if workers are closed to new ideas or so risk-averse that they can't chance failure, it's highly unlikely that any new knowledge will affect the way they do business.
These three ingredients result in a learning-distribution-change chain. In other words, the organization learns something, it distributes this knowledge, and organizational behavior somehow changes. Missing only a single ingredient can break the chain. If the organization can't learn from its experiences or the experiences of others, no new knowledge exists. If the organization can't maintain and distribute this knowledge, members won't learn about it. If the recipients of this new knowledge aren't willing or able to take it to heart, change won't happen.
A preliminary analysis of the problem of fostering a learning organization might lead us to believe that simply instituting a lessons-learned program would ensure a learning-distribution-change chain. However, the problem is much more complicated. I recently came across an article in which the author listed impediments to creating a learning organization. I'll paraphrase it here:
Few of us would argue these points. I've found these attitudes present in countless software development organizations I've visited. However, I found this list so striking because of its source. This list of impediments to fostering a learning organization is about police departments and is from an article by William A. Geller entitled "Suppose We Were Really Serious About Police Departments Becoming 'Learning Organzations'?" published in the December 1997 issue of the National Institute of Justice Journal ( www.ojp.usdoj.gov/nij/journals/jr000234.htm).
My conclusion from this is that software development shares many of the same issues that any professional organization encounters. Therefore, we need to pay attention to the solutions suggested in other domains.
We don't have the space here to discuss all of Geller's suggestions, but he offers one nugget of wisdom that is so profound yet so obvious that I simply have to write about it.
Geller relates a story about an organization that initially averaged only a single suggestion per year from each employee. However, within two years, the organization succeeded in averaging one suggestion per worker per week. This remarkable improvement was achieved by instituting two policies:
Adding feedback to the first part of the learning-distribution-change chain can do wonders in getting people involved in fostering a learning organization. It helps get people to note successes and failures and spend the time to develop their observations into suggestions.
If immediate feedback can foster contributions of ideas and observations, we might speculate as to the benefits of adding feedback into the last part of the learning-distribution-change chain as well. After all, we should value attempts to apply suggestions for improvement as much as we value the original suggestions themselves—if not more.
What do you think? I'd like to hear your thoughts on the issue of becoming a learning organization. Does your organization have a planned mechanism to solicit knowledge from employees? How successful is the mechanism? What are the keys to its success? Please write to me at firstname.lastname@example.org.