by Rachel O’Toole
My name is Rachel and I’m an agile coach. My admitting this is the first step in accepting it is my job — one that I didn’t think I wanted. Like anyone who takes on a new role, I was apprehensive. I had never done it before and although others thought this was just right for me, I didn’t share their opinion or enthusiasm. Instead I spent my days frantically Googling “How to be a good agile coach” in the hope that I would get a step-by-step guide I could apply. Unsurprisingly my “research” wasn’t very useful.
- In recent months, I have reflected on the reasons why I didn’t believe it to be an amazing opportunity and I came up with three:I was nervous of the people aspect of the role.
- I didn’t have the skills to do the job itself.
- And the most important one for me: I simply was at a point in my life that I didn’t want such a high-profile role.
Of those three things, I was ultimately right about one of them and that was that I didn’t have the skills. The fact that I didn’t want the job, yet was doing it, was difficult to adjust to. Over time, though, despite my best efforts, I came to not only be an agile coach, but I also began to enjoy it.
As I travelled down this path I also created a model.
This is the story of my journey to becoming an agile coach.
My past is haunting me
I work in a large multinational organisation for over ten years. We have transformed from a largely waterfall organisation to an agile software development house and have locations across the world. Within my development unit there are over 140 teams across five sites. I grew up professionally the very teams that I now operate in as an agile coach. I have worked in other places but not for long enough to say that they had a lasting impact on my professional development. Being in one workplace for over 13 years brings with it baggage. This baggage has good things: I understand the context in which my colleagues work, I speak the same shorthand language, I know all the people, and, better yet, I have been a developer on some of the products where agile development practices are being applied. To quote Olaf from Disney Pixar’s Frozen, “All good things. All good things.” and indeed they were. However, initially, I couldn’t separate myself from my past roles and found myself drifting back to what I knew and felt safe in, rather than fully embracing my new role as an agile coach.
Of course, I had changed roles throughout the years and I was — I like to think — valued and respected in them. I was Rachel the Software Engineer or Rachel the Scrum Master rather than Rachel the Agile Coach. My colleagues and I made a link between the roles I have held and who I was as a person, and this was bad baggage.
It resulted in my role getting diluted, impacting the value I could bring as an internal coach. External coaches wafted in and immediately made positive contributions to the organisation. Worse still, I tried following their techniques and failed miserably. I had expertise in agile frameworks and believed in the Agile Manifesto, so why was I not making an impact?
The eureka moment came when researching how to coach. Since Google failed me, I moved into the more traditional book route. The CCL Handbook of Coaching Organizations writes that one of the drawbacks of internal coaching is the credibility of the person, as they are unlikely to be able to compete in terms of the coaching hours and qualifications. Additionally, it states that the internal coach is not able to name the “elephant in the room” as readily and openly as an external coach because they must continue to work with the elephants after the discussion is had.
That was enough for me to realise that I should stop trying to emulate the external coaches and come up with my own approach while embracing my history with the organisation. This was the trigger for me to start creating a coaching model of my own that would help utilise the good baggage I brought and minimise the number of times I slipped back into my previous roles.
My coaching journey begins
My lack of competence in the role needed to be addressed. I decided to split the agile part of the role from the coaching part in the early days. I had deep experience in transitioning Waterfall to agile working practices, but lacked the coaching experience. I focused my efforts where I had no expertise, immersing myself in learning how to coach, by going on training courses, watching online modules, and reading every book I could find about organisational behaviour and coaching change. What I learned, I practiced with teams I had worked with in my previous roles, as they were happy to volunteer for my early failures.
The first course I attended was a one-day session called “Coaching for Performance,” which was useful enough. It gave a structure to follow and the fundamentals of how to keep the problem squarely on the other side of the table without taking ownership or volunteering to “help.” I applied the process diligently but mastering the process itself didn’t make for an effective coach. Some of the interventions fell flat. Now I realize I spent too much time obsessing about iterating through each step of the process, and not enough focused on the people.
The next course was on Neuroscience-based Coaching focussing on the teachings of David Rock. This was just what I needed. My background is in engineering and science so having a course that explained how the brain worked gave me something tangible to hook onto and meant I finally got the science part I needed to make coaching something I could do. As part of the training, we were expected to coach each other.In one session where I was being coached, something was suddenly unlocked. I was given the role of agile coach after I had just come back from maternity leave. At that point, I wanted to go back to my old job of Scrum Master and when I was told I was to now coach my colleagues, I was devastated because I thought I didn’t want the job. As the coaching session progressed, the conversation kept coming back to my first day back in work after the birth of my son and that I didn’t want the role of agile coach. Then, the coach repeated what I had articulated verbatim and I heard what I was saying for the first time. It was not that I didn’t want the role of coach; instead it was the fact that the decision about the job was made for me and not with me. It was a brilliant moment with the realisation that what I thought was frustrating me was instead something else.
I finally clearly understood what good coaching could do for people and invested heavily in practicing the techniques.
My first successful session as a coach was with someone who had previously been my line manager while I was a software developer It made me somewhat nervous but he was willing. In only a 30-minute conversation, he figured out what was the root of his own frustration and he made a major career decision as a result. He was elated and couldn’t stop talking, saying over and over “when you said” but I had not said anything other than reflecting his words back to him, acting like a conversational mirror for him to hear himself think. I had gotten out of my own head and let him have the headspace to think and talk. My witnessing of his own eureka moment was the start of me being able to identify myself as an agile coach, a title I started to embrace.
After focussing on just coaching for awhile, it was time to marry coaching with agile practices and principles. We are an organisation in transition, going through a transformation from traditional development methodologies to a more agile development approach. Having gone through that change in own my team some years earlier, I appreciate how hard it can be to understand that such a change, although not welcome, is necessary to meet evolving customer demands.
And this is how I developed six personas that allow me to be a better coach. Tomorrow I’ll tell you about them…
Do you play different roles to meet the needs of your team? Which hats do you wear? Tell us in the comments below!