What do I do? I’m an Agile Coach. Yes, I know. that doesn’t answer the question!
I can explain if you give me a minute or two of your time. To do that, I’ll define agile and coaching first, then share stories from my own experiences. It will get more concrete, I promise!
Agile was defined in in 2001 by a group of software development experts, and the definition begins with: “we are uncovering better ways of developing software by doing it and helping others do it.” (source). That feels like a good place to start for me.
Software Development is where I started too, in a programming job in 2001 (coincidentally, the same year that definition of agile was written).
I was a Cobol developer for six years, then Java for another six or seven more. I was more of a back-end developer, comfortable with databases and SQL, which became a useful bridge between the programming languages.
It was unusual to know both Cobol and Java where I worked too, so I became a bit of a ‘boundary spanner’ across teams and technologies.
Before that, in University I studied Business and French, majoring in Marketing, Intercultural Management, and Production/Operations Management. I went to France for two years, including the summer of 1998, when France hosted and won the FIFA World Cup. Happy days!
For the summer of ‘97, I worked in an Audi factory in Ingolstadt, Germany. It was a huge learning experience in a massive factory, building cars on a moving line, with Kanban cards and Andon cords, just-in-time stock management, and stand-up meetings focused on quality. In hindsight, I became a process geek that summer.
It might sound strange at first, but those experiences with different cultures, languages and processes were defining for me, and really helped me in my first programming job.
Also, developing software was a total grind! I laughed at Hollywood movie representations of rock’n’roll tech like ‘Hackers’, because my perception was more about the gritty, one-step-at-a-time challenge of getting things done.
Meanwhile, in the wider environment, IT Project failure rates were high, and it felt like the industry as a whole was looking for a better way. Programming teams in the 2000’s talked more and more about working in ‘a more agile way’.
I connected with that very quickly. I devoured books by Kent Beck, Mike Cohn and Henrik Kniberg. Agile wasn’t describing new ideas as far as I could see, but the word ‘agile’ really caught on! Today, the word is on the other end of the hype cycle, but the ideas it represents are still very valid.
Coaching. While this agile thing was getting talked about, software development teams also talked about coaching. Teams seemed to need some help moving to better ways of working and evolving them in the ‘right ways’.
Each team I worked in had a process coach role called a scrum master, and I quickly gravitated towards that role myself too. Eventually, I was told one day ‘you’re a scrum master now.’ But later, in 2007, my world really changed.
I had my first coaching conversation.
At a conference, I discussed my career goals with a coach, and that conversation helped me discover Lyssa Adkins’ book on Coaching Agile Teams. I could practically hear light bulbs in my head going ‘buzz’ as I read it : )
Today, the International Coaching Federation (ICF) is my reference for coaching. (There are other professional coaching bodies out there). Coaching is a ‘helping through talking’ kind of role, and I use coaching competencies to work in and with agile teams.
I am a professional coach and I love the sound of that. I’m very proud of my ACC badge, which I earned with a lot of tough learning, practice and personal development.
Professional (ICF) coaches listen actively and reflect client’s language in service of working towards the client’s outcomes. Coaches use metaphors and offer observations. They help clients to be future-facing, and to become more aware how to move forward with autonomy and accountability to themselves.
Autonomy is a critical component. Coaches provide people with ‘scaffolding’ for time to think and define those actions, but do not create co-dependency. ICF Coaches work within a defined code of ethics.
Agile Coaching. Now, imagine, instead of partnering with an individual to co-create goals and outcomes, you are working with a software team, or even a group of teams. Agile Coaches do this using coaching competencies, and they need expertise in other areas to be effective in their roles. Coaching competencies alone are not enough.
For example, I can help to evolve team practices, product management or portfolio management processes. I can develop training for agile teams or people. I might help with discovery or problem solving, or facilitating conversations, and all of these activities are different to ICF coaching.
So, an ICF coach is not an agile coach. Agile coaches can serve their clients by telling and instructing, by providing expertise. ICF coaches do not do this.
Agile coaches use more than just coaching in their roles, and in fact, there is a broad range of competencies needed to be good at it. It’s a tough gig!
I work to be better at it all the time, and it requires constant learning and development. That is one of the things that I love about this job.
A go-to reference for the skills needed to become an agile coach are in the Agile Coaching Growth Wheel: (https://agilecoachinggrowthwheel.org)
Getting More Concrete. What I do right now:
Define improvement goals: Prioritizing improvement goals and measures of success requires many conversations with people at all levels of an organization. Without that, I won’t be able to choose effective actions for improvement, or measure the effect of those actions.
Change Management: actually working on actions that support those goals. Working across organizational boundaries with things like communities of practice and helping to demystify and evolve understanding of ways of working across the organization.
Team Coaching: in software development teams, helping evolve practices that might improve efficiency, perhaps related to collaboration and decision-making, or to reduce process overhead and bureaucracy.
Developing Capabilities: boundary spanning from software development teams to other teams in the organization, helping everyone understand the intention of ways of working and guiding their evolution. Working alongside experts in change and agile, helping them guide their own efforts.
Leadership Development: vertical development alongside skills and practices. Helping experts discover that they have valuable knowledge. Helping beginners understand how to find the expertise they need.
To bring it back to the beginning, I believe I am still “uncovering better ways of developing software by doing it and helping others do it.”
So… how was this explanation?
If you have any questions about agile coaching, I’d love to hear from you!