Team Communication: Learning models
One of the problems I’ve noticed in several of the 'agile' communication mechanisms (such as the standup or dev huddle) that we typically use on teams is that they focus almost entirely on verbal communication which only covers one of our learning styles - the auditory learning style.
The Learning Models
The VAK learning style model describes a simple model covering the different learning styles that people have:
Visual - seeing and reading.
Involves the use of seen or observed things, including pictures, diagrams, demonstrations.
Auditory - listening and speaking.
Involves the transfer of information through listening: to the spoken word, of self or others.
Kinesthetic - touching and doing.
Involves physical experience - touching, feeling, holding, doing, practical hands-on experiences.
My own learning style is predominantly visual so I tend to find that a well drawn diagram will help me understand something far more quickly than a colleague spending 10 minutes explaining something using only words.
If the latter happens then I either find myself totally zoning out or mentally trying to sketch out what the speaker is saying.
In a team environment this would translate into ensuring that we use the whiteboard when trying to explain problems.
Sometimes just going to the whiteboard isn’t enough and we need to cater to the kinesthetic learning model which in software development terms would involve walking through the code.
I’ve never been involved in a team session where we went through a part of the code base together but I’ve heard from colleagues that it can be very helpful in some situations.
I think it’s important that we know what our favoured learning style is so that we can guide any discussion in such a way that it plays to our strengths.
In terms of software development
Although people tend to have different learning models my general observation is that we can move through the models from auditory to visual and finally kinesthetic depending on the complexity of what’s being explained.
I think it also partly depends on the experience of team members. For example, I’m now able to understand many more discussions which are purely verbal where previously I’d have needed a diagram or someone to show me what they meant in the code.
I think it’s important to look at the implicit feedback we’re getting from colleagues when explaining something to see whether or not the model we’ve used has been effective.
If it hasn’t then at least we know we have some other approaches to try which might be more successful.