Interview with Christina Ohanian
Hi there, my name is Christina. I am an Agile Coach and my work is focused on collaborating with individuals, teams and organisations to embed and enable Agile practices. My expertise include team building, team coaching, meeting facilitation and developing practices such as Scrum and Kanban with a touch of Lean thinking. I enjoy generating and collaborating on new ideas, exploring solutions to challenges and I am actively involved in various communities as a speaker, workshop facilitator and other volunteering opportunities.
Forgive my ignorance, but what exactly does an Agile Coach do and how does that differ from a scrum master?
This is a very common question and I would say the best place to start would be to describe the role of an Agile Coach and from there we can talk about the role of a Scrum Master, as the two are similar but do have their differences.
It’s worth noting (before we dive into this answer) that the two roles have somewhat evolved a little over the years and different organisations do have varying responsibilities of both the roles, so this is purely my view.
An Agile Coach is (at its core) an expert in different Agile practices for example Scrum, Kanban or Extreme Programming (XP) to name the most common few practices that sit under the Agile umbrella. Their expertise and experience usually spans across many different contexts and organisational domains, not just technical teams.
They work with operational teams such as People, Finance, Marketing or even Regulatory/Compliance (depending on the organisation’s context). Agile Coaches also tend to not be dedicated to a specific team because of their wider focus across the organisation.
To paint a better picture, an Agile Coach may spend half of the week facilitating Discovery workshops for a high level business initiative, with a cross functional group and the rest of the week coaching another team on user stories and breaking down backlogs.
On a side note, this isn’t to say that an Agile Coach can’t be dedicated to a team. Some of the best Agile Coaches I know simply love to master their craft and practice. So not only do they stick to one team, they also keep their focus firmly in the software development field.
On a slightly more philosophical note, Agile Coaches also tend to be agnostic when it comes to frameworks and practices, steering more towards coaching through principle mastery over guided processes (however that’s getting a bit too deep into the topic…perhaps for another time!).
A Scrum Master, on the other hand, is a specific role that has been created as part of the Scrum Guide and practice. A Scrum Master is essentially a Scrum expert who is dedicated to a team and whose responsibility it is to ensure their team understands and practices Scrum to the best of their ability.
A Scrum Master works closely with the team’s Product Owner to help shape and define the Product and sprint backlog as well as with the team members when it comes to sprint commitments.
So, what do these two roles have in common? Quite a bit actually, however let’s condense it down into three main pillars. Both a Scrum Master and an Agile Coach focus on people, products and processes.
Whether you’re an Agile Coach working across an organisation or a Scrum Master specifically working with one team, your focus is to ensure people are working together collaboratively, delivering value for their customer or stakeholder and have the ability to adapt to change as and when needed.
I see that you moved from testing towards an Agile focussed role - how did you find that adjustment and is there anything you learned as a tester you have been able to take with you as an Agile Coach?
For me, the move from software testing to a more Agile focused role was actually a very natural and a relatively simple adjustment in terms of the actions I took to make it happen. I knew I wanted to be in the Agile space, I was confident I had the skills and most importantly I had very supportive people around me who not only encouraged me to make the move, but they collaborated with me to make my move successful.
The challenging part of the adjustment was in fact more personal and internal facing. I had some challenges overcoming my doubts, fears and my imposter syndrome which were stopping me from succeeding.
Overcoming these doubts and fears was the hardest part of my move, which for me essentially came down to three key actions; Stepping out of my comfort zone and trying new ideas as often as I could with my teams (basically not becoming complacent and comfortable), making sure I was getting feedback from my teams and people I worked with to continuously improve my craft and lastly coaching myself and my mind with positive affirmations.
This final one was probably the one that had the biggest impact on my mindset and by extension my mental health, when it came to being brave to try new ideas and overcoming my personal fears of whether I would be ‘good enough’.
In terms of my learnings as a tester and taking these learnings into my Agile Coaching role, I will start by saying, being the tester I was, when I started my career, has massively influenced the type of Agile Coach I am today. There are two specific learnings that stand out for me; The first is always asking questions and the second is thinking about the end user. Let me expand here a little.
Let’s start with ‘always asking questions’. As an Agile coach, a lot of what I do is ask different kinds of questions, depending on the scenario and context. This is to enable my teams to think about the challenge at hand and to collaboratively figure out solutions. I help open up the possibility of options to solutions and this can come about by asking sometimes even the most obvious questions the team may not have considered.
The second learning is ‘thinking about the end user’. Now in this context I actually consider the end user my team, and this is why I personally appreciate this particular learning more than any other, as it has truly taught me the power and importance of empathy. I see my role as a servant leader, and so my approach to Agile Coaching is about building my skills to serve my team as best as I can.
Along this journey, I have also found that empathy and understanding the people I work with really help shape strong team dynamics and as a result this contributes to better outcomes, whether it’s delivery of work, happiness levels or even both!
What is one of the biggest misconceptions you’ve seen/experienced when it comes to Agile?
Interestingly enough the answer to this question hasn’t really changed even after eleven years in the industry. I still hear statements like ‘but doesn’t Agile make you go faster?’ or ‘Why is delivery still late, I thought we were Agile?’ and the best one ‘Agile doesn’t work because it’s slowing us down rather than speeding us up’.
There’s a number of things we could unpack as part of these statements and many discussion routes we could take, however to keep it short and to the point, let’s unravel what Agile is really about. One of my community colleagues, Geoff Watts articulates this really well;
“Agile is all about advocating individuals and interactions, working product, customer collaboration, and responding to change. An Agile way of working streamlines your product development process and harnesses the power of your teams. Simply put, Agile teams and organisations are more responsive, productive and collaborative.”
Agile isn’t about ‘being fast’ or speed.
Of course overtime as you build your understanding around ways of working and processes within your teams you can become more efficient and delivery of work can speed up, however this from my perspective is a by-product of the emerging benefits of Agile ways of working.
It’s about understanding what to build for your customer. It’s about being able to adapt to both internal changes in direction and external influences beyond your control. It’s about smart and effective collaboration and communication with the people whom you are working alongside to build your product.
Agile practice simply enables teams and organisations to get the right skills and expertise together, to have a focused direction and to satisfy customers through continuous delivery and regular feedback loops.
Your workshop at Let’s Test 2015 was my first experience with Sketchnoting. Have you been able to use your sketchnoting skills in any of your past (or current) roles? If so, how have you been able to incorporate that skill?
I remember that workshop very well. It was the first workshop that I ever co-designed and co-facilitated, so that one has definitely stayed in the memory bank. I also remember how daunting and uncomfortable it was for so many reasons, but the learnings were immense and I am so grateful for that opportunity.
Sketchnoting and visual communication has probably been my most widely used method of communication as an Agile Coach. I can honestly say there isn’t a workshop or discussion that I have been part of where visuals haven’t been at the centre of the session.
Every time I take to a whiteboard, especially for group or one-on-one coaching, how I explain and describe processes, scenarios or even theory is done through sketch notes, images and models. It’s actually my favourite part of what I do and my approach to coaching.
Many of my colleagues have actually pointed out how enthusiastic I also become when I start to visually describe ideas using sketch notes, which is really lovely to hear.
Graphics and images are such a powerful way to communicate and I would recommend to all those who are not just in a coaching role but in any role, to give it a go. The way in which people interact with visuals enables convergence of thinking and this can have such a deep impact on outcomes and solving problems.
You don’t have to be amazing at drawing, in fact I distinctly remember saying at the beginning of my workshop at Let’s Test 2015 that I couldn’t draw when I first attempted to sketchnote or to use sketchnotes for communicating with my team.
It was through practice that I improved (just like any skill) however it was the impact I experienced from using sketchnoting and visual communication that made me keep this skill in my toolkit as a coach.
On a slightly different note, when the pandemic hit and almost all organisations started to work from home, I did wonder and worry if I would be able to effectively use this skill again as our teams were no longer in the office or around whiteboards. Bringing sketchnoting into the digital space needed some adapting and skill development. I had to find a way to break through the barrier as I know the impact of not communicating through these methods.
This is where online tools such as Miro and Mural to name a few have been amazing and have enabled me to bring visualisation and sketchnoting back into the mix. Also having the whiteboard feature on Zoom and Google Meet has been really handy to simply switch to visual discussions just like being in a meeting room with a whiteboard.
Have you seen much change or anything evolve when it comes to Agile in the past 5-10 years? If so, what have you noticed?
I wouldn’t say anything specific has changed over the years in the Agile space itself, although the Scrum guide has been updated a few times with some new additions and a few rewrites, but nothing major.
What I would say is that there has been a massive growth in awareness as well as the adoption of Agile across many organisations for sure! I remember when I first started my career as a software tester, Agile had actually been around for a while, of course more predominantly in the software space, however I remember talking to many people outside of my industry and they had no idea what Agile was all about.
Over the last few years, I personally have seen a change in the number of industries outside of technology that are focused on embedding Agile ways of working within their teams and organizations. I have also had the pleasure of working with such teams for example Marketing and Sales teams, who have been keen to understand and embed Agile practices in their day to day work, to help them become more adaptive, self organising and focused on improving their workflows.
Today when you say the words Agile, Scrum, Scrum Master or even Kanban many more people are familiar with these terms. More recently, I have even encountered interviewees who have been studying Agile in their university degrees, which is very encouraging!
On the flip side, I have also encountered a level of criticism around the fact that Agile, the Manifesto and the Principles haven’t really evolved over the years. This one is an interesting discussion to deep dive into and we won’t be able to get into this here, however I do encounter more and more software development teams who want to ditch ‘Agile’ because they feel there are ‘too many constraints and limitations’.
As an Agile Coach, it does make me wonder, as tech stacks continuously evolve and specialising in a specific skill becomes more of a standard factor to take into consideration, perhaps there is a need for deeper collaborative discussions between the Agile and Software Development communities.
If someone wanted to become an Agile Coach, what advice would you give them in terms of actually getting that first role and also tips on how to be an effective agile coach?
When it comes to getting that first role, there are a number of things I would suggest to consider and advise:
1. Do your homework! Just like any role you would want to apply for, find out as much information as you can. I would recommend reaching out to Agile Coaches you have worked with in the past or perhaps current ones in your organisation if they exist. This will give you a good insight into what being an Agile Coach is like day to day and expectations of the role. Make sure you’re asking the questions that give you insights into not just opportunities but the challenges you might face, as well as logistics, benefits and progression. All these conversations can be the start of helping you decide if this is a step you really want to take.
2. Find out if your current employer is hiring for an Agile Coach. You would be surprised how many people don’t consider this route. Depending on the context, this could very well be the easier option compared to going for both a new role with a new employer at the same time. Of course, that’s not to say the latter option isn’t the right one either. This might work better for you and your context, however if the first route is an option, especially if you really love the company you work for, well let’s put it this way, you move into your new role, your company gets to keep you and is able to benefit from your new skills, it’s a win-win. One other route is also perhaps creating a new role in your organisation if the role does not exist. Have you ever considered this approach?
3. Test out the waters and put some of the skills you might be using into action. I remember one of the key things I did before I made my move was to find opportunities to be an Agile Coach. I would take on being the ‘guest facilitator’ for many retrospectives and workshops (both in my organisation as well as for other external organisations), I would get involved with discussions on Agile topics in the internal communities of practice and I even spent a week or two shadowing another team’s coach. Testing out these skills (early and often if you can) gives you so much more of an insight, and for me this particular step has proven the most valuable.
4. Find a good mentor or coach. I personally, have had one or two key people who have been a real support system, especially at the time of my move. It never hurts to have someone with whom you can soundboard ideas, ask advice and someone who can be a great support for the journey ahead. Of course finding the right mentor or coach is key, and I do appreciate this can sometimes come at a cost, however there are many brilliant platforms and online communities you can reach out to who offer many great options! I would also be more than happy to share any information if readers are interested.
5. Attend recommended training courses*. Now, I have put an asterisk(*) next to this one for a reason. I will be honest, I am not the biggest fan of training courses, and it’s also why I have used the word ‘recommended’. Training courses are a great way to learn and build knowledge about a topic, skill or practice, however there are so many options out there and don’t forget, they are just training courses. Applying what you have learnt ‘in the field’ is just as important if not more. We have all heard the stories about people attending training courses and suddenly they are seen as experts, however this can have damaging outcomes for both the employer, the individual and the teams who are impacted. If a training course is something you really want to do then I suggest finding courses which have been recommended. Again, ask an Agile Coach you know or perhaps you can reach out to team members, who might have worked with some great coaches in the past or might know great courses they have taken themselves. Again do your homework, don’t jump on the first course that you find when searching on Google.
6. If you get an interview, accept it and use it as a means to practice! Of course, if you get the job off the back of the first place you apply for, amazing! On the other hand if you don’t…don’t be disheartened. Every interview is a chance to learn, grow and practice. I still get no’s from employers and in some cases I have even rejected offers as well. In both scenarios, being able to practice is massively valuable and I find it’s a great way to exercise the mind muscles, which we don’t get to use on a daily basis.
When it comes to being an effective coach, I feel like that’s a whole separate interview there in itself, however I will keep it very simple and leave you with my top five tips, which coincidentally spell out the word ‘LEARN’:
Listen to understand what is actually being said.
Embrace the unknown, there is usually a spanner in the works somewhere.
Always ask the obvious questions.
Reflect internally for your own growth.
Never underestimate the power of empathy and patience.