Knowledge transfer is characterized by transfer of understanding, about a context, from one unit (individual, team, department, organization) to another. Most organizations, spend a considerable amount of time documenting their understanding so that the knowledge transfer process becomes smooth and efficient. While Agile does not discourage documentation, it does place emphasis on “Working software over comprehensive documentation”. In a series of interesting experiments, Steve Bockman tried to figure out the best way to transfer knowledge in an Agile project.
For the experiment, Steve tried to transfer knowledge about a product which was an unusual paper plane in three ways. He used the following strategies,
Documentation - The workers were given written instructions (22 steps worth) for building the airplane.
Reverse Engineering - The workers were given a completed airplane which they could study in order to reproduce the steps required to build it.
Mentoring - The “chief designer” built an airplane step by step and the workers replicated each step as it was performed.
The experiment was conducted with 8 participants for a total duration of 5 minutes for each scenario. The results were amazing.
Only 12.5 % people were able to complete the assignment by referring to the documentation. Using the reverse engineering method, 25% of the participants were successful and with the mentoring method 100% of the participants were successful.
This certainly points in the direction of healthy communication and mentoring as the best way to transfer and share knowledge. Steve added that this principle holds even more value for software development which is based on constant communication and feedback. According to him,
Let’s say I’m a developer who has discovered, and written the code to implement, a technique for binding some data to the controls in a user interface, and that this technique forms a pattern that my fellow developers want to know about. If you were one of my fellow developers, would you rather I (a) gave you a document I had written about the technique, (b) told you where the code was and suggested you figure it out for yourself, or (c) paired with you to implement the pattern for a new set of data?
Young Ye and Royce Fay, suggested another way of efficient knowledge transfer using Asymmetric pair Programming. The essence of this method is that apart from pair programming between developers, it also happens between developers and domain users. Again, the stress being on human communication than documentation.
One of the well known benefits of pair programming is quick knowledge sharing and transfer. Agreeing with this, Alan Skorkin suggested,
The most important benefit in my opinion is the fact that pairing is highly conducive to organic knowledge transfer (”pairing is knowledge sharing” for the poet in you). I believe this is key since in a large system there is literally no other way to do this well.
Thus, there is a general agreement that the best way to transfer knowledge is by communication, mentor-ship and working together. Though, some amount of documentation might be helpful, but solely relying on documentation would yield limited benefits.
Community comments
The Mentor Bottleneck
by Frank Smith,
Re: The Mentor Bottleneck
by James Couzens,
Re: The Mentor Bottleneck
by Balaji D Loganathan,
Re: The Mentor Bottleneck
by d l,
Re: The Mentor Bottleneck
by Frank Smith,
Re: The Mentor Bottleneck
by d l,
Re: The Mentor Bottleneck
by Frank Smith,
Need for a stable team for knowledge retention
by Udayan Banerjee,
Value of pairing
by Dave Nicolette,
Re: Value of pairing
by Frank Smith,
What is your team size?
by Mohamed Faramawi,
Re: What is your team size?
by Dave Nicolette,
Re: What is your team size?
by Vikas Hazrati,
Re: What is your team size?
by Frank Smith,
It's a venture to organization that a person have much knowledge.
by 一 刀,
The Mentor Bottleneck
by Frank Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
I've seen software development organizations where the person with the knowledge didn't write anything down and just collaborated with people to transfer knowledge. It doesn't scale well when the knowledge needs to be transferred to more than a few people. This approach was a huge knowledge transfer bottleneck compared to some good documentation and availability of the expert for a few clarifying questions.
Re: The Mentor Bottleneck
by James Couzens,
Your message is awaiting moderation. Thank you for participating in the discussion.
I would have to agree with this. In the case when the mentor is available it works 100%, when they are not it drops to 0% unless there is some other way of doing the knowledge transfer. This suggests in general you will need a multi-modal knowledge transfer approach.
Re: The Mentor Bottleneck
by Balaji D Loganathan,
Your message is awaiting moderation. Thank you for participating in the discussion.
If the knowledge has to be transferred to multiple people on different occasions, then its better to video record the KT sessions.
An idea would be to ask the Mentor to prepare the screen cast on the KT.
Regards
Balaji D Loganathan, Spritle Software
Need for a stable team for knowledge retention
by Udayan Banerjee,
Your message is awaiting moderation. Thank you for participating in the discussion.
Success of agile depends on open interaction among individuals. Without a stable team it becomes difficult. Here are my thoughts - setandbma.wordpress.com/2009/02/25/unstable-req...
Value of pairing
by Dave Nicolette,
Your message is awaiting moderation. Thank you for participating in the discussion.
Is there really much doubt that pairing is useful for knowledge transfer, after all these years? What I often see people overlooking is the value of pairing for ensuring high code quality. That seems to be less intuitively obvious to people than the benefit of knowledge transfer.
Yet, it's clear that I'm mistaken to make that assumption. Based on some of the comments here, it seems some people assume "mentor" is a special individual who may or may not be available. I see every team member as a mentor, when and as necessary, using the seamless, effortless, cost-free, automatic, and organic mentoring method: Pairing.
The only thing that puzzles me is the fact that (apparently) this isn't perfectly obvious to everyone.
What is your team size?
by Mohamed Faramawi,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well it depends on how big your team is, if its a matter of 4 or 6 developers, then pairing , or lead by Example is great.
But what is your team is 10, or 20 , what will you do, you can't pair with them tall, you can use the lead by example approach.
What if you team is > 20.. well you can still use previous techniques, and let who you taught ,teach who you didn't , only if they have the spirit.
But in my opinion, documentations will always be needed, its just a matter of how much docs you will write, and when.
What i think is, every agile team should have a technical writer who catch up whatever devs share together and take care of sorting preparing these stuff, it won't be a good technical document, but somehow it will be useful, and others can benefit from it.
It's a venture to organization that a person have much knowledge.
by 一 刀,
Your message is awaiting moderation. Thank you for participating in the discussion.
When a person dismiss, the knowledge will lost.
Re: The Mentor Bottleneck
by d l,
Your message is awaiting moderation. Thank you for participating in the discussion.
If a Mentor transfers his knowledge to 3 guys, so these 3 guys can mentor other people, which can mentor other people, ad infinitum.
Re: Value of pairing
by Frank Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
Speaking for myself, I don't doubt that pairing is useful for knowledge transfer. And yet, that is irrelevant to my original comments. Lot of mechanisms are useful for knowledge transfer (pairing, documentation, email, phone calls, happy hours, conferences, workshops, ...). I do believe that some people in the Agile community overhype pairing at the expense of other useful ways to transfer knowledge. As for "mentoring", practically speaking, over time it's not uncommon for a few individuals to acquire both deep and broad knowledge of a complex system. In the workshop described here, it would have been interesting for the pairees to then try to "mentor" others who had never build the paper airplane. I'm guessing it would have been a bit humorous. In any case, this workshop represented more of a training class model than a pairing model. I think you may be puzzled because you're not seeing the big picture.
Re: The Mentor Bottleneck
by Frank Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
Try pairing a surgeon with someone who has some basic first aid training. Have them do a complex operation together, perhaps heart surgery. Send the newly mentored "doctor" to mentor 3 more people in open heart surgery. I predict very poor results.
Try the same experiment with an commercial jumbo jet aircraft pilot transfering knowledge to someone with experience limited to flying small planes. Again, it won't be a good outcome. Now I agree that after numerous "pairing" sessions it might work.
However, in both these examples there's a lot of written documentation involved for a successful knowledge transfer along with pairing.
Re: The Mentor Bottleneck
by d l,
Your message is awaiting moderation. Thank you for participating in the discussion.
Try giving a surgery book to somebody with basic first aid training. Let him do open heart surgery. What is your result prediction in this case?
Re: What is your team size?
by Dave Nicolette,
Your message is awaiting moderation. Thank you for participating in the discussion.
I wonder if 20 or more people can actually function as a team, regardless of the working methods they use.
Re: What is your team size?
by Vikas Hazrati,
Your message is awaiting moderation. Thank you for participating in the discussion.
That is indeed a very good question. @Mohamed, do you intend to split your team into 2,3 teams?
Re: The Mentor Bottleneck
by Frank Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
I predict a bad outcome. And that supports my point. A combination of collaboration and documentation is often more appropriate than either collaboration or documentation alone. However, in less complex contexts either can probably succeed without much of the other. Pairing can succeed with minimal documentation. Documentation without pairing can also succeed in many contexts. Product documentation is one common example. Many people learn how to use products based on written documentation and no personal collaboration with product experts.
Re: What is your team size?
by Frank Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
Sure. I've worked on successful XP teams of 20-ish people. For larger teams than that, Vikas' comment suggests the answer. "Pods" can be created of 5-10 people each. However, now you have a new set of challenges. Can pairing work effectively across pods or is it better to provide some interpod documentation with the option to ask for personal assistance (collaboration) when needed?