One of the challenges I’ve to address quite frequently in system designs is knowledge transfer. For instance, some years ago one of my clients was in the situation that they have a lot of COBOL code in their system. That’s not really a problem as such, however they noticed that COBOL developers die out slowly 🙂 So what are the options? They could probably tell their two remaining COBOL guys to sit in a corner until they retire and write down everything they know about their COBOL systems. Well, I am rather pessimistic that this will lead to a big success. Don’t get me wrong. I see quite a lot of value in documentation, nevertheless when it comes to knowledge transfer, there are much better ways to succeed.
When I was confronted with this situation the first time, a former experience from an XP team came into my mind. When we tried to figure out the WIP limits for their kanban they told me it must be something around 0.5 per person. Wow, half a work per person! That doesn’t sound right. However, what they were (and still are) doing is pair programming which means that each user story is developed together by two persons. This inherits a lot of benefits. One of the biggest benefit was that knowledge about their system is spread among all developers. Ahhhh… That’s exactly what we need for our COBOL guys. We want to spread the knowledge about the COBOL systems. Guess what we did? We set the WIP limits to “number_of_persons – 2” (there are two COBOL guys). Furthermore, we introduced a policy that each of the COBOL veterans has to work on a ticket with another guy. And guess what, it really worked. Knowledge was transferred and more and more people were aware of what’s actually going on in the COBOL system.
Today, I propose this pattern every time when we have to address knowledge transfer in the improvement work. It is not always easy, especially if companies are trying to utilize their “resources” as much as possible. But that’s another very long story… The explained pattern is the very basic idea of how to handle knowledge transfer. In later articles I will describe more variants.