Exploratory Development

Knowledge management is quite a controversial topic. Some companies invested big resources into knowledge management projects and didn’t get expected results. Due to these failures knowledge management is considered by some companies as just yet another “silver bullet” which doesn’t provide any real value. Some companies believe that by managing knowledge they can solve all their problems.

It seems that the truth is somewhere between. Knowledge management is not a silver bullet, but it can improve company’s bottom line by making its operations more effective. Mostly it is targeted long-term goals – optimization of company’s work (but mainly in the future), development of staff. It provides better information for making decisions because knowledge sharing increases transparency. Calculating numerical outcomes of knowledge management projects is not an easy task, but often it is much easier to calculate losses if such project is not implemented.

Companies tend to start global revolutionary projects in this sphere, despite of the fact that large projects are seldom successful. It’s a smart move to take into account statistics and split project into smaller parts:

• Having several smaller parts provides a company possibility to change strategy after implementation of each part – a company can use results of previous stages in implementation of the rest, it can change, cancel or add new phase;
• Big changes almost always meet resistance from people – when people are tired of changes they will ignore or even sabotage new projects. Splitting a big project into smaller ones can allow to separate phases in time and to give people time to get used;
• A company gets results quicker – after every part.

Another common misconception is that new technologies (e.g. ontology, knowledge base, etc) automatically improve knowledge sharing. Without appropriate corporate culture people will not use technologies. Yet technologies can help to share knowledge by making it easier.

Let’s take a look at some practical ways to share knowledge in a software development company. These methods don’t require serious investments or new systems, while providing value to a company:

• Processes
• Common practices
• Internal conferences/camps
• Trainings
• Common retrospectives
• Team review
• “Scrum of Scrums”
• Success stories
• Common place

Processes

Processes have been used to share knowledge for a long time. Industry-wide processes (e.g. RUP, OpenUP, Scrum/XP, Prince2, etc) contain knowledge of many companies. Implementation of such processes gives a company some external knowledge. But these processes don’t take into consideration company’s specific features and environment, that’s why companies tailor standard processes to their needs. Changes can be made on the level of a specific project or on the level of a company. When it’s done on the level of a company it shares knowledge between projects, although sometimes company-wide processes don’t fit specific project’s needs and it causes reluctance in adopting them.

Too detailed processes lead to bureaucracy and strong resistance from the most talented people. Processes which define too little provide little value. It’s very important to balance process scope and provide additional flexibility to get maximum value and avoid resistance (which can lead even to key personnel loss).

Common practices

Another way is to share some basic process which is obligatory to follow and set of practices which may or may not be followed. This approach solves problem with resistance while ensuring best practices sharing. Main problem is to persuade people to share their knowledge.

It can be organized in any form (e.g. on Wiki), although it’s important that:

• It is easy to add practice (e.g. no special software is needed)
• It is easy to browse practices
• Lots of people know about this catalog of practices
• Practices are not forced to be used

Some good ideas:

• Practices may have rating based on frequency of use
• Practices may have rating based on usefulness (these two ratings can be used together)
• Contacts of people who can explain practice in more details and provide some help
• Practices description should be quite short but enough to understand the main idea
• Description should contain links to documents that elaborate this practice

Internal conferences

Internal conferences can be organized in different formats, for example:

• Lectures and workshops with Q&A sessions;
• Camp – main idea is to discuss burning topics with experienced people, a few prepared workshops and potentially mini-lectures are possible

Lectures and workshops format is very common. One important detail – give the audience (usually the most interested part) some time to communicate with lecturers informally (e.g. after conference).

Camp format is more informal. Here is a way to organize camp.

In the beginning list of topics to discuss are generated and selected (because number of generated topics are usually more than it’s possible to discuss) by all participants (number of participants should be not very big, better no more than 30 people). After topics are selected they are distributed into groups and timeslots. Open-space format is used for discussion. For every group there is a separate area with flipchart, white board, etc. People can move between areas.

Example of schedule:

	Group 1	Group 2
10.00 – 11.00	Ice breaker. Topics generation
11.00 – 12.00	Retrospective	Product backlog
12.00 – 13.00	How to build a team?	Scrum Master and his responsibilities
13.00 – 14.00	Lunch
14.00 – 15.00	Project tracking	How to avoid resistance to changes
15.00 – 16.00	Definition of done	Workshop “Estimating in story points”
16.00 – 17.00	Scrum and OpenUP	How to demonstrate advantages of agile to a customer
17.00	Informal part (e.g. bar)

Trainings

Trainings are especially useful when a company needs to get some external knowledge.

But trainings can be used to share internal knowledge as well. If there are highly skilled professionals with good presentation and lecturing skills then it’s reasonable to use them as trainers.

Common retrospectives

Retrospective is a good way to gain experience, but this experience usually is not spread. There are some ways how to share this knowledge:

• Invite people from other teams to retrospective
• One person (or team) is responsible for sharing this knowledge – s/he participates in all retrospectives and share results between teams
• Results of retrospective get documented

All these methods have drawbacks:

• A team usually doesn’t want any outsider on retrospective
• It’s hard to ensure that knowledge is spread among all teams not only between some of them
• Some teams may not want results of their retrospective get shared (but if some teams publish their results then it’s likely that other teams will begin to publish too)

It’s a smart move not to take approach “one size fits all”. A company should choose approach according to situation.

Team review

One (or several) person from outside a team analyzes how a team works. This review should not take much time, mostly reviewer(s) has to understand how a team addresses usual challenges (requirements management, project tracking, etc). After finishing review this person provides some recommendation on how to improve team’s work. And in the same time during analysis s/he gets additional knowledge, possibly some new best practices.

“Scrum of Scrums”

In Scrum there is such term as “Scrum of Scrums” – when several Scrum Masters working on the same project but in different teams have their regular meeting. A company can use this approach at higher level (e.g. not project, but department. All teams should be split into several groups (for example, by departments). Delegates from teams (Scrum Master, Project manager, any member of a team) regularly meet up and discuss their problems, new practices, ideas, results of using some practices, etc. From time to time groups’ composition needs to be changed.

Success stories

People like success. Why don’t describe teams’ achievements? And include into these stories how they achieved success – it will help to share best practices. In addition it increases satisfaction of successful teams and their motivation.

Common place (e.g. kitchen)

Last but not least. Actually, that’s the most effective way to share knowledge – just give people possibility to communicate. Although there is a change that knowledge sharing will occur only in closed groups. To improve communication a company can add some tools – whiteboard, flipchart, etc.

Knowledge sharing is a part of corporate culture

People are the most important part. And main task is to demonstrate advantages of knowledge sharing for people and for company in general while reducing overhead. If people understand benefits and it doesn’t require much effort they will share knowledge thus making themselves and a company stronger.