EarlS Schools of KM
Knowledge Management in Software Development Knowledge management is “a method that simplifies the process of sharing, distributing, creating, capturing and understanding the company knowledge.”1 Knowledge itself “is a fluid mix of framed experience, values, contextual information and expert insight that provide a framework for evaluation and incorporating new experience and new information.”2 Furthermore, “knowledge passes through different modes of conversion, which makes the knowledge more refined and spreads it across different layers in an organization.”3
The main assets of software development are not manufacturing plants, buildings and machinesbut the knowledge held by the employees and the development culture of an organization. Companies developing information systems have failed to learn effective means for problem solving to such an extent that they have learned to fail. The key drivers for companies to manage knowledge effectively in software development are:
• Reducing the effort spent in acquiring required knowledge for project execution.
• Improving reusability (i.e., avoiding reinvention).
• Reducing dependency on individuals for project success.
• Improving the overall team’s productivity.
Knowledge Types
Typically knowledge can be classified into two types, explicit and tacit.
Explicit knowledge is knowledge that is articulable and transmittable in formal, systematic language. This can include grammatical statements, mathematical expressions, specifications, manuals and so forth. Such knowledge can be transmitted formally among individuals with ease.
Tacit knowledge is personal and context-specific, and is therefore difficult to formalize and communicate. It is embedded in individual experience and involves intangible factors such as personal belief, perspectives and value systems. Tacit knowledgeis difficult to communicate and share in an organization and thus must be converted into words or other forms of explicit knowledge.
The Knowledge Lifecycle in Software Projects
The knowledge life cycle in software projects can be described in five steps.
1. Gather available explicit knowledge. Generally, this happens during the start of the project whereby available knowledge is captured and made available in knowledge bases, marketing, different departments, etc.
2. Personalize explicit knowledge. The gathered information/knowledge needs to be converted by the individuals involved in the projects into tacit knowledge.
3. Application of the acquired knowledge. Converted tacit knowledge will be applied to the project execution.
4. Learning from the project. There could be some learning, innovations or new methods or techniques uncovered during the execution of the project which will be in the form of tacit knowledge.
5. Convert to explicit knowledge. The learning needs to be converted into explicit knowledge and added to the repository for future reference.
There are many questions related to knowledge management, especially in Agile projects: How different is it to manage knowledge in Agile projects? What should be the relative levels of focus on explicit knowledge vs. tacit knowledge?
This paper will address these queries.
Knowledge Management in Traditional Software Development
Traditional software development approaches organize the required knowledge sharing based on different roles following a Tayloristic4 mind-set: people involved in the development process are assigned specific roles (e.g., business analyst, software architect, lead designer, programmer, tester, etc.) that are associated with specific stages in the development process (requirements analysis, high-level design, low-level design, coding, testing, etc.).
Limitations Knowledge sharing between each of the stages is primarily document based (i.e., through explicit knowledge). One role produces a document (e.g., requirements specifications, design documents, source code, test plans, etc.) and hands it off to the people responsible for the next stage in the development process. Assuming merely 5% of relevant information is lost in each transfer between the stages, nearly a quarter of the information does not reach the coder (who has to encode the domain knowledge into software) in a Tayloristic development process. The results are even worse if more than 5% is lost in each stage. Another problem resulting from the long communication chains in Tayloristic software organizations is a tendency to over-document. Information is useful only when it is new to the receiver; providing a known fact to somebody is old, boring news.