When you observe a well-knit team in action, you’ll see a basic hygienic act of peer-coaching that is going on all the time. Team members sit down in pairs to transfer knowledge. When this happens, there is always one learner and one teacher. Their roles tend to switch back and forth over time with, perhaps, A coaching B about TCP/IP and then B coaching A about implementation of queues. When it works well, the participants are barely even aware of it. They may not even identify it as coaching; to them, it may just seem like work.
Whether it is named or not, coaching is an important factor in successful team interaction. It provides coordination as well as personal growth to the participants. It also feels good. We tend to look back on significant coaching we’ve received as a near religious experience. We feel a huge debt to those who have coached us in the past, a debt that we cheerfully discharge by coaching others.
The act of coaching simply cannot take place if people don’t feel safe. In a suitably competitive atmosphere, you would be crazy to let anyone see you sitting down to be coached; it would be a clear indication that you knew less than your coach about some subject matter. You would be similarly crazy to coach someone else, as that person may eventually use your assistance to pass you by.
Source: Peopleware – Productive Projects and Teams, Third Edition, Tom DeMarco and Timothy Lister, Dorset House Addison-Wesley, 978-0-321-93411-6
The dissemination of the Agile approach has bring in the headlight the notion of “coaching” which could be sometimes just a nicer word than “consultant”. There is however some places where the self-organization of the team is really implemented and the coaching approach is needed. In this case, I recommend the very good book written by Lyssa Adkins: “Coaching Agile Teams“.
Without being directly related to Agile, Tom DeMarco and Timothy Lister emphasize the importance of coaching in software development. This quote reminds me my days as a software development student when we were a small group of friends working in a collocated space. There were no competition between us, only the aim to learn some new aspects of the programming language and tools that we were using, helping then our friends if they needed it. I have found this same type of relationship in some projects where we would mentor each other.
An Agile team should operate on the same mode. In cross-functional teams there are people with varying expertise or degrees of knowledge. Cross-mentoring should be a key aspect of Agile teams. Pair programming is a technical practice that should be associated to this type of behavior if the developers have an open mind.
Even if you title is not “coach” or your project is not “Agile”, being able to share and receive knowledge of your software project teammates should an important part of your professional and personal development. In software development, everybody should be a coach!