In Chinese philosophy, yin and yang (also yin-yang or yin yang, 陰陽 yīnyáng “dark—bright”) describe how seemingly opposite or contrary forces may actually be complementary, interconnected, and interdependent in the natural world, and how they may give rise to each other as they interrelate to one another. – Wikipedia
If you read a previous posting about technical v non-technical Scrum Masters you might find this update of interest as we explore combining the two types.
A little over a year ago I was pleasantly surprised to have that previous article referenced by Bob Galen on the Velocity Partners’ blog. Bob’s article was a discussion on the pros & cons of a Scrum Master having a technical background, and also referenced an article by Manjit Chana containing the important alternative perspective on the subject. I’m now in a position, with Manjit’s help, to provide what I hope is an interesting update and extension to the debate.
Update
For the last six months I have been lucky enough to have the opportunity to work alongside Manjit on a new project working with a number of Scrum teams. We’ve taken the opportunity to not only recognise our different backgrounds and experiences, but to try a number of experiments in ‘pair coaching’ to explore the potential benefits of combining our skills.
Manjit and I have many lengthy discussions – it’s not that we don’t agree, it’s just that we see things from completely different perspectives. We’re both completely signed-up to the Agile Manifesto, Principles and associated mindset, but we often come at a problem using different language and sometimes it takes us a little while to work out we’re saying the same thing. After a few occurrences we started to recognise the issue earlier and began finding ways to reach a point of shared understanding more quickly. It’s much like any other new team learning to work together and finding the practices which work best.
High performing teams are greater than the sum of the individuals involved, and we have seen a number of benefits in working as a ‘pair’ when coaching individuals or teams as a whole. The advantages of Pair Programming have long been understood – why should developers have all the fun!
Benefits
Manjit has helped me understand the importance of the language and words we use. My technical background has always allowed me to find a comfortable place when talking to developers but it’s a dangerous place to be with the perils of being sucked into ‘solutioning’ and potentially missing some of the wider issues that the Scrum Master should be reflecting to the team.
On the flip side there have been occasions where I have been able to jump in and improve understanding by translating from ‘techie’ to ‘plain English’ allowing Manjit to provide insights of her own.
We are able to freshen up the experience for our teams with a ‘two heads are better than one’ approach to retrospectives and other team meetings and it has been interesting to compare the results of the same retrospective format being run in parallel with two teams using two different coaching styles. Perhaps most unexpected is an apparently sub-conscious ability to switch roles as required – whether it’s good cop/bad cop or optimist/pessimist. At any moment in time one of us seems to better positioned to address the reality of a situation and a natural state of balance exists – the Yin & Yang of the title.
On a personal level our other differences include competitive/non-competitive personalities, ethnic and cultural influences, views on certification and obviously gender, amongst many others. We hope to be exploring some of those in more detail and their potential impact on our complimentary coaching styles in future postings. Manjit will be sharing her thoughts in a follow-up to this posting. (Update: Manjit’s perspective can now be found here)
Ultimately, simply having two coaches in the room (even without different skills) provides numerous advantages such as greater observation and facilitation of any discussion. Any coach can experience a moment of brain fail and having a standby available, who is up to speed and can provide a new perspective, can be priceless. With our experiences so far and based on feedback received from the teams we’re working with, there seems little doubt of the value it can bring.
Can you help?
We’d like to investigate the potential offered by pair coaching in more detail and have already had some discussions with friends and colleagues from the Agile coaching community. If you have any relevant experiences then we’d really appreciate hearing from you. We suspect that in order to maximise the benefit, it is important to have as many differences in the two coaches as possible but we’re lacking empirical (or even anecdotal) data to prove it.
We guess few teams will have the luxury of having two coaches and exploring the possibilities offered, but if you think it’s worth a try in your environment then do get in touch.
