This one seems a bit strange to me, as it almost seems obvious and common sense. But then I guess we all know that common sense isn’t that common!
Thinking about the fact that the origins of Lean are in manufacturing, where the traditional approach is to simplify and standardise everything to the point where no knowledge is required, like on a factory line, then I guess it’s clear why this principle was originally such a different way of thinking.
In software development, we all know that knowledge is paramount. We’ve all had situations where there’s only one developer that can work on something, at least productively, or even at all. Nothing beats the knowledge that’s created when someone actually writes the code.
Although I’m not particularly an advocate of Pair Programming, this is a specific agile practice from XP (Extreme Programming) that helps to ensure that the inherent knowledge that comes from writing the code is held by at least two people, rather than one.
So, if knowledge is important, and helps the longer term productivity and flexibility of the team, you need to take some specific actions in the short term and put some specific things in place to ensure that you create it.
Exactly what you do, as always, depends on your particular situation. Here are some things you could do on your projects to help create knowledge:
- Pair Programming
- Code reviews
- Wiki – to let the knowledge base build up incrementally
- Thoroughly commented code
- Knowledge sharing sessions
- Use tools, such as tinyPM, to manage requirements/User Stories