In my article “Knowledge Transfer with Kanban” I explained the very first experiences I made with knowledge transfer policies in kanban systems some years ago. I convinced quite a lot of organizations to give it a try when they faced this problem. In an audit with a client who introduced knowledge transfer through WIP limits I got the feedback that it works – but not under all circumstances. They reported two situations when it does not work for them:
- When you want to transfer knowledge to a rookie but the work is much too specific. You would have to explain hours until the mentee would understand what you are talking about.
- The work is too general. No knowledge transfer is needed because everyone could do the work on his/her own.
A short remark to the second case: We know there are still good reasons for working in pairs not only for knowledge transfer but this is, however not part of this article – and no, I could not convince them to still work in pairs on these tickets. You know, it’s not always easy to argue flow in capacity optimizing cultures…
Knowledge transfer makes sense – but not in all cases
In general one could say knowledge transfer makes sense – but not in all cases. So the solution was straight forward: we visualized it!
In the figure above you can see a divided input queue: WT and IQ. IQ stands for Input Queue and WT is an abbreviation for the German word Wissenstransfer which means knowledge transfer. And that’s exactly what it is – we have two input queue columns: (i) work where it makes sense to transfer knowledge and (ii) work where it doesn’t make sense. We introduced a policy like “whenever a senior developer discovers work that’s worth for knowledge transfer she puts the ticket into the WT column. A pair is build and they work on the ticket as a team”. Easy, isn’t it?
After a couple of weeks the client reported back that the number of knowledge transfer tickets was greatly reduced. However, this was not the intention. As a consequence they changed the wording of their policy to: “Whenever a senior developer discovers a work which is NOT worth for knowledge transfer, she puts the work into the IQ column”. See the difference? They basically made it the default case to transfer knowledge. They reported back that the number of knowledge transfer tickets was increasing again. Of course they also discussed the issue in a retrospective and rose the developers awareness that knowledge transfer is the expected behavior.