Software engineering is a knowledge-intensive activity. Software companies are more likely to beat their competitors by creating novel ideas than by simply using a lot of capital to achieve economies of scale. Because of that, these firms depend proportionally more on intangible assets, such as skills of their workers, rather than tangible assets like offices or machinery. Software companies achieve competitive advantage by leveraging their unique resources, one of the most important being their intellectual capital. Those that know more, for instance have more experience in using software design patterns to solve performance issues, are able to create products of better quality and better return on investment. As a result, knowledge management has been an important consideration for large businesses and now 80% of the large corporations have knowledge management initiatives. In principle it may seem obvious that the more experience the company has the lower the likelihood of developers getting stuck and repeating past errors, but in reality it is not that simple for a large software firm to successfully accumulate its experience and knowledge and achieve sustainable organisational learning.
Why do we need knowledge management?
Advancements in technology and demand for software require software companies to improve their productivity proportionally more to the increase in their resources. Companies would preferably want their performance to keep improving from project to project. They would want their workers to increment their own experience bank by adding new information that was gathered during the course of their last development and use it to tackle new tasks more easily. In current volatile environment, developers come and go and their knowledge comes and goes with them. When new employees are hired, they are not able to use the experience of the people they are replacing. The knowledge of previous workers used to solve bugs or make design decisions is not accessible. If faced with similar problems to the ones solved by the company in the past, new developers may not know exactly how to approach them. With every worker change there is therefore a knowledge drain and organisational memory loss due to the lack of perfect transition of knowledge from one employee to another. Knowledge management is a currently topical discipline, which aims at diminishing this issue. This practice encourages mechanisms for developers to utilise previous engineers’ work, whether it is code or information stored in a knowledge repository on how to approach certain problems, which leads to less rework and faster development progress. Implementing a knowledge management system involves introducing not only new technology, but also organisational change such as culture or human resources adjustments. For instance, because the knowledge repository may not benefit the workers now, but few years from now, they may see contributing to knowledge pool as a burden, as it would not directly benefit them and their current situation or performance. They may also feel that technology used today will be obsolete in the future and see little sense in trying to describe learning from using it, as future workers may not even need this information. This calls for for instance cultural change inside the business whereby leadership of the organisation strongly supports and encourages workers to contribute to the knowledge management initiatives. As much as 50-60% of new knowledge management initiatives still fail, because technological change is not introduced parallel with the process change.
How can knowledge be shared?
Knowledge carried by workers can be divided into two types: explicit and tacit. The former refers to the easy to articulate information that can be represented as documents, graphs or tables. This could for instance be a document displaying software duration estimation model developed by previous employees and explaining the reasoning behind it. The latter covers the intangible, difficult to pin down know-how of a person – their gut feeling, experiences, perceptions or attitudes. Examples of that could be how to deal with a specific customer or a specific design issue. To make the best use of the knowledge that is being created in the business, it would be in the company’s interest to establish mechanisms that would allow for a knowledge flow between team members. For instance, a company could set up an information system used as a repository for explicit knowledge – an organised catalogue of all the evaluations of previous projects stored in files accessible by workers at any point. Through these repositories developers could find out how to approach a new project based on what worked or did not work in the previous one. They would internalise this explicit knowledge and turn it into a tacit knowledge by increasing their know-how. At the end of their project, they could evaluate their work, for instance by doing a post-mortem analysis, and sustain the acquired knowledge inside the business by publishing the evaluation document into the repository for future colleagues to use and learn from it. Knowledge management systems could also grow larger and span not only project evaluations, but all the files used in the project, which could make them either potential knowledge gold mines filled with interesting past learning or unusable, obsolete files that work against the purpose of achieving competitive advantage through improved decision making.
Would experience database scenario be viable in real life? In many cases it is not.
Knowledge management in traditional software development methodologies
The software methodologies are divided into traditional, which follow the waterfall model-like approach, and agile. Traditional approaches divide the development into a series of independent steps. They start with eliciting requirements for the product to be developed, they analyse them, negotiate them with the stakeholders, clarify them, develop them, test them and deliver the finished product to the customer. The development team in traditional approach is divided into sections, each of which has specialised capabilities. These work on their own responsibilities and do not participate directly in the work of the other group. For instance, when doing requirements engineering at the beginning of the process, the team allocated to this step would construct documents listing all the use cases that need to be captured by the system and then pass it to the development team which will translate these into code. The requirements engineers do not step into coding and vice versa, programmers do not interfere with the product features elicitation. Development that uses traditional software methodologies is a long, as it allocates a lot of effort to pre-production even before any coding starts. Structured approaches allow for more space to analyse each of the steps to be able to make educated decisions on how to best approach them, as later on these decisions will be difficult to amend, as the development process cannot easily iterate back to previous steps. They allow for time to retrieve previously generated knowledge from the repositories and use it to improve current project’s decision making and therefore performance. They also are able to introduce structured and systematic methods of creating knowledge artefacts and sharing them with the organisation. Traditional methodologies may be more suitable for large software development. Large products are complex and one design decision may have a proportionally more impact on future progress of the application than if the system was smaller in scale. The time spent by workers on analysing previous knowledge and the expenditure of the firm on developing and maintaining knowledge repositories may be more justifiable, as it may result in better decision-making and less errors that may have a negative impact on the return on investment in the product. The process if not managed well can become inefficient. If all the employees, let’s say two hundred, are required to explicitly state what they learn and contribute that knowledge to the repository, it may create a database filled with irrelevant information, which is difficult to browse through and use to aid future decision making. The quality of the repository stops the knowledge from being retrieved and therefore stops the workers from contributing knowledge to it as they may feel that it simply does not make sense to spend time in an unusable information system.
Examples of knowledge management in the industry
Large software development company Infosys has for many years pushed an approach to store all the knowledge gained by employees in an organised and monitored for quality repository. Initially after an introduction of the knowledge management information system the company did not see much effort being put from the employees to share their experience and evaluate the work they do in the business. In its first year the information system saw only 5% of developers contributing to the knowledge pool and even less using it to retrieve information. Infosys realised that voluntary contributions to the knowledge management system will not work and that cultural change and incentives mechanism are necessary for the knowledge pool to grow. They have introduced a gamified system whereby developers could gain virtual currency for sharing their experiences, which could then be exchanged for real life products or money. This attracted workers to contribute with 20% of them sharing information. Unsurprisingly however, after several months the company realised that the knowledge inside its database was of low quality and revised the incentive scheme, which had a negative impact on the amount of knowledge shared. Infosys nowadays still runs a common knowledge repository and states that it faces biggest challenges with extracting knowledge from software teams working together across many locations.
DaimlerChrysler involved in developing software for its car electronics, established a unit inside their organisation called Software Experience Center. The SEC was aimed at investigating how the process of software development can best capture knowledge that it creates and codify it for future use and learning. It used the notion of “experience factory” whereby a group of people is working inside the organisation and is specifically assigned to project analysis and evaluation to identify aspects that may improve future projects. This is then shared in a common knowledge repository, which ensures quality of the content inside it. DaimlerChrysler said that this approach is viable, however only when managed properly. They stated organisational and human resource challenges as the biggest obstacles to successful knowledge management. For instance, they said that knowledge leaders tend to overestimate the motivation of workers to contribute to the knowledge initiatives.
Both of the companies are large and have established methods that turn experiences of workers into explicit knowledge available for the rest of the organisation. Their strict processes allow for standardisation of what knowledge and of what quality is put into repositories, to contribute to better knowledge retrieval in the future. Today’s business world constraints however require firms to develop products rapidly and efficiently, as time and budget are one of the most prominent customers’ expectations. They also put pressure on development firms to allow for changes to be made throughout their software projects as their product requirements may have changed since the inception of the development. Often, instead of traditional methodologies, companies therefore use agile methodologies such as extreme programming to accommodate for the dynamic software environment and reduce the risk of developing a product that will not satisfy its stakeholders.
Is agile the answer?
Agile methodologies create organisational cultures that encourage cooperation and learning from each other. They have interpersonal communication at their core, which is reflected as “Individuals and interactions over processes and tools” in agile manifesto. Companies using agile design their work practices to include group meetings and constant information sharing between developers. These practices help with transferring tacit knowledge – the difficult to articulate attitudes and perceptions of workers. These can be shared using methods such as pair programming. Using this development practice, a worker who has been exposed in the past to a particular design issue can instruct his partner on how to best approach it and solve it in current context. Also, through pair rotation the entire team will share similar knowledge, as partners will transfer experience between each other each time they rotate. This increases organisational learning and sustains the knowledge in the business as now if one of the workers would leave the company, the information would still be with the other workers. Agile methodologies diminish the barrier of work processes being separated from knowledge management processes, as knowledge management happens simultaneously with development in agile.
Transferring tacit knowledge between team members may prove beneficial, however to truly sustain all the knowledge in the business, the company would want to transform the tacit knowledge of workers into explicit knowledge available to all the employees in the organisation (for example by publishing documents into previously mentioned repositories). Because of their intensity, agile methodologies however do not leave much space for sustainable knowledge creation and retrieval. Coding starts from day one, as soon as some initial meetings take place, without much space for analysing previous work to find out patterns or approaches that could be used in the current project. They are aimed at lowering the product’s time-to-market and do not leave much space for workers to articulate their learning throughout their work. Also, after the project is finished and developers have the time for evaluation, the context-specific nature of the software they developed does not allow them to properly share ideas and information for future use, as they would either have to convert these into abstract format applicable in many contexts, which would take a lot of their time, or share it as it is, which may not be applicable in future projects.
Agile methodologies share knowledge well inside small teams located in the common workspace. They allow for weaker knowledge transfer in distributed software development for instance when one company has few agile teams working in separate offices distributed globally. Because of the lack of common repository for knowledge, workers are only able to transfer both explicit and tacit knowledge between workers in their workspace and only explicit knowledge for instance in the form of version control with workers in distributed places.
In my opinion, knowledge management appears promising only on the surface. In theory it can help the company achieve unique competitive advantage over their rivals and utilise intellectual capital resource of the business. However as displayed above, there is no approach that is ideal for facilitating knowledge sharing in the organisation. Traditional approach to software development may seem better in case of large scale projects as it incorporates space for evaluation, formal decision making or sharing explicit knowledge, which sustainably improves the organisational knowledge pool. The bureaucratic fashion of knowledge sharing in these methodologies may cover all the knowledge created by workers in the business, but that may not necessarily reflect itself in improved performance if knowledge repositories are badly managed, never used or obsolete. Because of many challenges to optimal knowledge sharing, leaders of companies have to therefore not necessarily optimise knowledge sharing, but “satisfice” – satisfy some part of it by sacrificing another. Agile methodologies work better in transferring tacit knowledge between workers, which arguably may contribute to the firm’s competitive advantage more than explicit knowledge, as tacit knowledge directly improves the skills and know-how of developers. Agile may be an answer to knowledge management of large projects, as it satisfies tacit knowledge transfer pretty well, while sacrificing risky bureaucratic practices, which output may not result in competitive advantage in the future.
 Schneider, K., von Hunnius, J.-P., Basili, V.R. 2002. “Experience in Implementing a Learning Software Organization”, IEEE Software, 19(3), pp. 46-49.
 Kimble, C. 2013. “What Cost Knowledge Management? The Example of Infosys”, Global Business and Organizational Excellence, 32(3), pp. 6-14.
 Schneider, K. 2002. “What to Expect From Software Experience Exploitation”, Journal of Universal Computer Science, 8(6), pp. 570-580.
 Rus, I., Lindvall, M. 2002. “Knowledge Management in Software Engineering”, IEEE Software, 19(3), pp. 26-38.
 Levy, M., Hazzan, O. 2009. “Knowledge management in practice: The case of agile software development”, ICSE Workshop on Cooperative and Human Aspects on Software Engineering, 2009. CHASE ’09. pp. 60-65.
 Dorairaj, S., Noble, J., Malik, P. 2012. “Knowledge Management in Distributed Agile Software Development”, Agile Conference (AGILE) 13-17 Aug. 2012, pp. 64 – 73.
 Desouza, K.C. 2003. “Barriers to Effective Use of Knowledge Management Systems in Software Engineering”, Communications of the ACM, 46(1), pp. 99-101.
 Bjørnson, F.B., Dingsøyr, T.“A Survey of Perceptions on Knowledge Management Schools in Agile and Traditional Software Development Environments”, Agile Processes in Software Engineering and Extreme Programming Lecture Notes in Business Information Processing, Vol. 31, pp 94-103.