This is the second post for implementing Lean in Knowledge Work based on Harvard Business Review article here, you can read my previous post about visualising waste here. When trying to make knowledge explicit, we should appreciate the following:
- People are non-fungible. People differentiate themselves based on their character and ethics.
- Skills are levelled: We will continue to have people of varied degree of competency in certain skill.
- Having knowledge explicit will never replace people and their interactions.
Instead of the above, making knowledge explicit intends to:
- Allow people to focus on non-repeatable work.
- Have common standards of doing work for defect prevention.
- Improve predictability by producing repeatable reliable results.
I have been a Scrum Master for a project who implemented entirely new cloud technology. Even experienced Java developers needed to learn many new pieces and went through long experimentation before they become able to provide predictable work with acceptable quality. The value of codifying the knowledge of how we create functionality using the new technology was very high. It allowed us to predict velocity and dramatically reduced negative feedback during testing with other systems. We should strive for studying tacit work and relentlessly codifying it if possible.
We cannot specify the work for all activities, remember people are non fungible. We will continue need people with exceptional abilities who can help in unusual situations. Also, we should avoid specifying work initially, it requires time to study the work then codifying the knowledge for what is appropriate.
The challenge in codifying knowledge is that many skilled people think that this is not possible. The success factor is to ensure their job satisfaction via non repeatable and challenging work while asking them to codify what is repeatable.
Finally, there many activities in software projects which can be specified and become repeatable to produce economy and quality to the organisation at large.