I’ve been pair coaching the past 6 months with Kelvin Lawrance. We wanted to experience and explore the benefits of pairing as we felt it shouldn’t just be limited to the developers around us. It’s been an amazing experiment and journey and I’d like to share a few discoveries for those who might be interested.
So, Kelvin = technical, me = not technical i.e. I do not speak a programmers language. It was after writing an article on fear that we both felt compelled to explore our differences. At this point I’d like to thank Bob Galen for his perspective in his article here.
In a few words, Kelvin is a technically minded scrum master and coach. Reassuring in his approach, and capable of helping anyone understand agile and framework/method theory and implementation effortlessly; having that unique ability to switch in and out of guiding, mentoring, and coaching as and when needed, AND to have a language that was shared with developers, I quickly realised that we were 2 very different types of scrum master. Both of us wanted to explore what the other seemed to ‘have’.
Just over 6 months ago, an opportunity arose to work at the same place, in the same office, and there our pair coaching journey began…
Here are some of my pair coaching discoveries:
1. Using technical language as a tool:
So Kelvin is the technical one and despite the ongoing debate over whether a SM should be technical or not, I have finally had the opportunity to really understand where the value is. And so did Kelvin. It’s a language. Obvious to most, but stay with me…
I’ve found that if you’re technical, you understand a language that gives you a communication skill that non techies don’t get to enjoy and take advantage of. It’s just that not all these techie SM’s use it that way. At first (in the early months) I felt Kelvin was getting involved where he shouldn’t, and we had frequent debates and disagreements over this – trying to understand whether it was ‘right’ for an SM to get so technically involved. I felt that he was indirectly teaching teams that all SM’s should be able to converse using a coders language and able to offer technical solutions too.
The tricky bit for Kelvin once he also realised this technical involvement was then to really use this technical language as a communication tool to help teams, WITHOUT getting involved or invested in the solution. This was an incredibly interesting journey of struggle that I got to observe and feed back on. It was a struggle for me too as we both tried to find the balance. It still continues even today, but SO much less.
These days…
6 months in, I have seen Kelvin focus more on using his language skills to facilitate technical discussions, and no longer providing technical solutions.
I see him these days bring a team to conclude on difficult technical conversations and be a mirror in those conversations by translating and reflecting back what they are saying to help improve or create a shared understanding when it lacks. I have more difficulty in doing this, as would many non technical SM’s. We facilitate at different level, not necessarily comparable to how techies would facilitate.
Pairing has allowed Kelvin to see himself through another SM and improve how he uses his technical mastery. It’s a journey I have observed in almost every meeting, workshop, conversation that we have been involved in with teams. Our guess is that I wouldn’t have appreciated this about ‘technically minded SM’s’ and he wouldn’t have been able to make those changes if it weren’t for ongoing pairing where we are challenged and open to being challenged on a daily basis by one another, in real time, as well as after the event.
2. The power of conflict:
Kelvin has been a real shock to my system as we are just total opposites. Like Yin and Yang; strangely compatible (but it requires work!).
Our opposing views created a lot of level 1 type conflict. I often had to revisit what I thought I knew and already understood about myself and what my ‘job’ is in this scrum master role. We always think we know best, and our egos are hurt when we are shown that sometimes we don’t. Conflict occurs when we aren’t so open to that. This kind of conflict came about on a regular basis as we seeked to understand each other and dig deep into the beliefs, behaviours, understanding and approaches we had. It came from a place of passion, and served us in remaining determined to pair – to GROW.
It’s through this conflict that we learnt the most; after all, how much can you really learn from someone who thinks and sees things the way you do?
This brings me onto self awareness.
3. Self awareness
The combination of real time feedback and post event reviews about approach, messages etc. increased our awareness of who we are/have become in our role over time. It’s helped us understand more about our individual approaches and how they can be compatible to serve teams together. We have also been able to learn how to take on an alternative world-view. We cannot always see or know what we are until someone shows us…and on countless occasions, it’s been a hard pill to swallow.
This awareness is easier to take on board and address when it comes from someone you have formed that pairing bond with; you trust each other, and it’s almost like it’s part of the ‘contract’; an expectation that you’ll be honest with each other – because ones performance, thinking, behaviours etc. will naturally impact the other whilst you’re working together.
4. The subtle difference between pairing and reviewing
If you suspect you have gotten used to your own way/style of thinking/processing information over the years, pairing removes the veil off the mirror that now provides real time, constructive, in-the-moment suggestions and insights without undermining you – much as developers get from each other when they pair. Careful to note this is not like the code reviews which may sometimes happen after the work is done.
Kelvin and I gave each other feedback in-the-moment, and then discussed that feedback afterwards if we wanted to explore it further. This was a new experience for me, and quite magical. A fellow colleague was giving me information I could use to improve and course-correct immediately, if I chose to. Sometimes, I chose not to act at all – but it was a choice I had.
In summary
Pair Coaching has been a rewarding and much needed path to self discovery. I believe I speak for us both on that one. I feel I have reflected and grown at a faster rate than I ever have whilst working ‘alone’ i.e even with fellow scrum masters who are in the same building. I have been forced to revisit what I know through real time feedback; a mirror that is constantly in view, but also develop skills in helping another to succeed and grow.
Conflict has definitely been the most unexpected element of pairing but I think we’ll both talk more about this in a future article.
If you need some stretching, or are intrigued by what you may discover about yourself and another, why not think about pair coaching too?
At the start of our pair coaching journey we asked ourselves, “Why can’t we pair coach? Why is it just developers doing it?” And now we ask, “why aren’t more scrum masters pair coaching?”
I am hoping that by writing this article we might hear from others who are on a journey of pair coaching, have perhaps done it for some time, or are interested in exploring and practising it.
It may come as no surprise that I have paired on various parts of this article with Kelvin. Some during the writing, some afterwards. I’m happy to admit that it’s better than it was when I started writing it alone.
