Completely Mental

It just so happens, that one of my favourite pastimes is following the proceedings of a little sport called football. For esoteric reasons, I happen to support a British team called Queens Park Rangers. Just recently I came across a forum post with a link to
this 1988 documentary on the team’s mental training at the time. In it, viewers are introduced to how a sports psychologist works with the team during six weeks. Players learn to focus on matters they wish to be good at, and to visualize themselves doing them.
They also get to do team sessions where they discuss problematic areas during the past season, and where they get the chance to express their feelings about situations on the football pitch. The impact of this mental training is deemed a success, with several of the players improving their focus areas. From the manager’s viewpoint, the team also started to communicate on a whole different level than what was ever imaginable before the training.

Fascinating, isn’t it: an activity based on strength, stamina, genes, hard training and ball juggling talent can be improved by psychology! Oh, and that’s why I came to think that the act of mental training is greatly underappreciated in the world of software development, and is frankly something that I don’t think many teams or companies are doing. Sure, the Agile retrospective is something along the lines of what I’d like to see, but it encompasses so many areas not related to how we feel or communicate with each other.

I don’t have a Ph.D. in Psychology, but I reckon that just by applying some commonsense we can immediately identify some things:
1. When we visualize ourselves doing hard things, or talk about things we fear, we inadvertantly improve in these areas. With continued mental training we unlearn unwanted habits while discovering how not to fear our most dreaded scenarios. I argue that visualizing writing clean code actually makes you write cleaner code, or maybe more indirectly, sets your mind in a state more open to learning things you need to know to write cleaner code!
2. When we get the chance to express our feelings about softer topics such as why you are hesitant to refactor legacy code, or why you fret about pair programming, or what you really think about the new process being pushed upon you from above, we immediately feel better about them. As a group, we bond together instead of building mental silos. Opportunities for adaptation arises instead of slipping through our fingers!
3. In reference to my previous review of The Two Second Advantage, when doing this kind of training, you are in effect building mental models of your particular focus area. These mental models include knowing how other members of your team will react in certain situations.

Maybe my argumentation is a bit abstract, so let’s just think about a few things I’ve noticed “out there”: People realize pair coding, peer code reviews, TDD, etc, are indeed very useful practices, but for one reason or another they repeatedly ignore following them. Or what about people sitting at their desks/cubicles/work stations deciphering a cryptic email from someone from another department across the hall for 30 minutes, instead of walking over to that person and resolving the confusion. Most of the time this has to do with fear; fear of not knowing how to do something, fear of not knowing what something will be like, or fear that something would be too much work or too boring! Venting such fears opens up for peer understanding and relief which in turn might push a team to try some of the practices out. The team and its members will grow, as a unit as well as individually.

As for how you can accomplish this in practice, well, unfortunately I don’t have much experience on the matter. But I suggest introducing the topics of mental training in the company, and encourage people to get together and talk about them as often as they want; on Lean Coffes before work, or during team meetings, or on extended or separate retrospectives, or preferably over a beer or two after work!

As always, experiment, evaluate, improve.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>