Community managers have a tough job. They deal with lots of different stakeholders trying to find that elusive “middle ground”. They incessantly cheer on community activities and push adoption of collaboration best practices; but when it comes to validating their position through tangible and quantifiable metrics it can sometimes seem daunting. Is the best measure user participation? How about community size? Each of these seem like great things, and they are, but typically organizations don’t have a lot of tolerance for soft measures that don’t directly impact the “bottom-line”.
Recently I have been working to identify ways in which organizational performance gains can be tied to community activities. Since my current position involves helping large organizations increase performance from their development teams, I started first by looking at something that may seem far removed from community, knowledge reuse.
Why reuse? The reason I chose to build my case around reuse is that the potential for productivity gains is huge. Let’s do some simple math to illustrate the point. Let’s say a development organization has 1000 developers employed. The industry average indicates that a single developer will write somewhere in the neighborhood of 3200 lines of code per year. That’s 3.2 million lines of code! At an industry cost per line of code of $27 (taken from Applied Software Measurement by Caper Jones) that’s approximately $86 million in software development costs per year!! Wow! If we can replace just a fraction of that development effort with reusable components and establish a process for interweaving reusable assets into all software projects we can save an organization millions of dollars per year!
In this post let’s first look at the process of reuse and in later posts I’ll follow up with some specific suggestions for creating an effective reuse program.
Reuse has five specific phases with hurdles between each phase that impedes progress to the next stage. Overcoming these obstacles will be key to the long-term success of your reuse efforts.
During this phase knowledge is converted into something that is explicit and consumable by others. This phase represents the transfer of one person’s understanding, education, and wisdom into a tangible good. The publication format can be nearly anything – a blog, wiki, software artifact, anything that is consumable by another person.
Publication events are of very low value unless they can clear the first hurdle for reuse, Findability. Findability describes how readily available information is to other users in an enterprise. Enterprise strategies to increase findability include document repositories, index and search, push notifications, and categorization and taxonomy. Increasing the findability of assets requires a solid understanding of knowledge asset usage and user behavior.
The Discovery phase begins when another user in the organization tries to find an answer to a problem relevant to them. During this phase the output of the publication event is found and analyzed for relevance against a new problem. This can be done via search, browsing, or by someone sharing a document via email. This is a particularly important phase because without discovery the publication event will go unused and is of very low value to the overall organization.
During this phase information has been found but may not be fully understood by the consumer. This phase is a critical component of the Reuse Process because it promotes and encourages questioning and full understanding of the material.
Collaboration tools are essential during this phase of the process. The requisite for any collaboration tool is that a question and answer can take place to facilitate understanding between parties. To better disseminate information and to make it more accessible to others in the future, public exchanges should be used when possible. Communication channels like phone, IM, and email are great mechanisms that enable questioning and understanding but also limit the consumption of this “give and take” process to a very few parties. This sometimes is sought after behavior but in many cases the Reuse Process would be more effective if the discussions where held in public forums that are fully searchable and have meta-data such as comments and reviews that can be associated with the artifact.
The next phase of the Reuse Process is the Extension phase. In this phase we are applying the knowledge, wisdom, and education that was distilled in the original artifact into scenarios that we own and are a part of. In this way knowledge has been transferred to us from someone else and used in, perhaps, totally new ways. The context of the original information may only tangentially apply to these new scenarios, if at all. The idea being that because of someone’s published work we have been able to grow our personal knowledge base and now have the ability to extend a concept into a new area.
A great example of the extension of knowledge into new areas was the seminal work by Christopher Alexander “A Pattern Language: Towns, Buildings, Construction”. In this book Alexander makes the case for developing construction practices based on the fundamental notion that harmonious patterns have existed in architecture for centuries and that these patterns should be reused if they add value and harmony. This work was later applied to computer science by several researchers, most notably Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides and a new field in computer science was formed with the same basic tenets applied to computer science as Alexander had originally written about. This example clearly demonstrates the Extension principal (although on the extreme perhaps) that allows knowledge designed for one audience and context to be discovered, discussed, and transformed into another entirely different area of study.
The last phase is the Integration or Reintegration phase where changes that impact the original artifact are integrated back to improve the original. Integrations can take on several different forms from comments and ratings on a document to bug fixes or functionality enhancements for a software artifact.
The key to integration is to understand the need and desire of others to contribute and to provide the support and infrastructure that allows community and organizational knowledge to flow back into the original artifact. Conclusion
As development teams organize more and more around driving value to the end customer via Agile methodologies, I see reuse as an area that could be overlooked easily without a unifying process. Project teams become focused on delivering their user stories and forget the bigger picture of component reuse because a) it was not budgeted for the sprint or b) no teams are working horizontally across the various project teams to discover reuse artifact candidates. But this post has gone on for long enough. I’ll post again soon and ferret out some of these issues.