Hello Yoan! First of all, can you introduce yourself in a few words and tell us more about your background?

My name is Yoan Thirion, I’m 34 years old, and I’m an independent technical agile coach in Luxembourg. I have about 15 years of experience in software development.

My different experiences in startups, small software companies, or in the service industry led me to code on a wide range of platforms/technologies and languages: mobile app development on the ancestors of our “smartphones” (J2ME, RIM, Windows Mobile, …), .NET stack (C#, F#, C++), PHP, Java stack (Java, Kotlin, Scala), SPA (Angular mainly).

I started coaching about five years ago when I realized that I liked helping other developers and learning every day.

I am an enthusiast who is always eager to learn and share with others (#sharingiscaring).

Let’s get straight to the subject. In your own words, what does Technical Agile Coaching consist of?

In a few words, I would summarize it by coaching “agile” teams that do not necessarily have all the elements to deliver iteratively and incrementally. Basically:

• With Agile coaching: we set up a framework to “build the right thing” in the best possible conditions (” Build the right thing »);
• With Agile Technique coaching: we focus on implementing engineering practices and the acquisition of knowledge that allow us to deliver quality products continuously (“Build the right thing”).

Here are some examples of tools that I “push” within the teams I coach: Clean Code, Test Driven Development, Pair/Mob Programming, Methods for refactoring legacy code (Mikad, Approval, …), Code Reviews, Domain-Driven Design, Technical Retrospectives…

My daily goal:

• Help individuals to grow/acquire new technical expertise, agile and human, to deliver high-quality software in the most efficient way possible;
• This is done by making them autonomous in their practices and learning (developing the ability to adapt).

What are the initial issues of the clients?

The same issues or improvement areas often come up:

• Agile or DevOps initiatives that struggle to take off or fail;

• Teams that need to deliver high-quality products and code but are constantly under pressure and don’t have a second to invest in quality, resulting in an uncontrollable increase in their technical debt;

• Developers who must implement and use best practices that are not defined or shared;

• Autonomous but not technically aligned teams;

• No space for continuous learning and, therefore, potentially for constant improvement.

What are your objectives?

The medium-term objectives (a few months) from the sponsor’s point of view are to succeed in helping the coached teams to move towards “better.”

This improvement often translates into an increase in the quality produced by the team, which can be measured by the decrease in the number of defaults in production (or on lower environments).

To bring the teams to the best, I always start by aligning their current situation. I use a self-assessment template containing a dozen categories/cards to do this. I make sure that each team member has a say on each card:

• Describe the current situation
• Identify areas for improvement
• Present their ideas for action/experimentation

Once this exercise is done and a first analysis (mini-exploration of their source code and their architecture) :

• I have a first idea of actions that could bring improvement
• I propose them to the team
• We create a backlog of actions to be carried out in the next few weeks.

For example: materialize our guidelines, do 1 Clean Testing workshop in order to understand how to write better tests, do 1 code review in mob programming in order to increase our alignment on the code, and avoid code reviews in ping pong mode, …

We replay the self-assessments every three months to validate or not the progress.

Warning: when you use this kind of self-evaluation tool, I advise you to keep them within the team; otherwise, they may be misused (see Goodhart’s law).

Did you initiate this self-assessment model and these cards? How and when did you get the idea?

It is freely inspired by the Henrik Kniberg’s Squad Health Check created a few years ago at Spotify to measure the impact of the continuous improvement process on the teams and the organization.

You can freely reuse the cards available here.

In your opinion, are there any skills (soft and hard) needed to accomplish these missions?

In her book “Coaching Agile Teams”, Lyssa Adkins represents the job of the agile coach with a model to understand the different facets of the role.

I have been inspired by it to create this model which represents (at least at the beginning of 2022) my point of view on this profession.

From this representation, we could easily attach specific skills and knowledge.

To be able to accompany development teams, you need to have a solid background in development:

• Mastering several programming languages (with different paradigms: procedural, object, functional) ;
• Have an excellent knowledge of software engineering practices (CI/CD, testing, architecture).

In addition to these hard skills, you must also be able to:

• Facilitate workshops ;
• Communicate with anyone in the organization and therefore adapt your communication to your audience;
• Understand others and show empathy;
• Help others grow by imparting knowledge and coaching (using open-ended questions).

Concretely, are you 100% of the time with a team? Is there a typical day?

No, I work with several teams every day in different contexts (I have 5 clients simultaneously right now). There are not typical days but rather recurring types of activities: 

• Preparing workshops (technical or not) or code katas;
• Facilitating workshops;
• Animate communities;
• Do Code Reviews with a team;
• Leading technology watch sessions (cf Xtreme Watch)

At Promyze, we have created a collaborative format for knowledge exchange and the Craft Workshops’ best practice alignment. Do you think this can help you in your missions?

Yes, I see Promyze as a platform to accelerate cultural change. It allows us to systematize/sanctuary collaborative exchanges on code through Craft workshops. The platform will allow anchoring these workshops in the routine of the teams, allowing them to :

• Align themselves with their coding guidelines
• Take a step back from their code
• Dedicate time to continuous improvement/learning on their code, architecture, …

This is clearly a tool to be used by all technical agile coaches. 

What are the conditions for a successful coaching mission?

For coaching to be successful, there are 2 essential factors:

• The support of the management to free up time for the teams;
• Establishing a coaching “contract” with the teams being accompanied.

When I talk about a contract, it is not necessarily something very formal, it can be for example: where we are today and we want to be in a certain amount of days.

This allows us to set a goal and give ourselves objectives.

Do you rely on (or are you inspired by) some existing coaching methods?

Absolutely, I use many tools from coaching. For example, I use :

• A derivative of Jason Little’s Lean Change Canvas to materialize the vision of the communities I coach (more info here);
• GROW to support teams (Goal / Reality / Options / Will more info here) and to structure the coaching approach;
• The Solution Focus in retrospect or in team coaching allowing to shift the focus on the solutions rather than on the causes/problems;
• Many Management 3.0 tools such as Delegation Poker;
• Training from the Back of the Room for the design of my workshops in 4C mode allowing me to create participative and engaging trainings / workshops.

Do you have any practices or workshop formats that you prefer during your coaching sessions?

In order to demonstrate the relevance of certain practices or techniques, I conduct code katas with the teams. The katas allow us to learn new concepts (Approval Testing) outside of the team’s code and to pass on messages in a benevolent manner. There are many repositories of katas such as coding-dojo, katalyst or kata-log. 

We can imagine that some people in the teams may be reticent to change and to evolve their practices. How do you handle these cases?

That’s why it is essential to have a coaching contract with the team. This “contract” commits each member of the team to respect the choice of the majority. Obviously, the world isn’t just rainbows and butterflies and some people are more receptive to this kind of initiative than others. I also count on the most motivated (Early Adopters) to convince the most reluctant. 

What other daily challenges do you face?

The reality of projects or products often catches up with us. The time that the team can give themselves for continuous improvement and learning may be less or more important depending on the period and the organization’s reality (rushes and unforeseen events will always exist). It is part of the coach’s daily routine to manage these periods of weakness with the teams being coached. It is often an opportunity to explore new topics and prepare new workshops for the teams. 

Is it possible to measure the impact of your support? With which methods?

The impact of the intervention of a technical agile coach can be measured in several ways: 

• The feeling of the team (with the Health Check mentioned above or surveys allowing to get the feedback of the coached people);
• Via quality probes: code coverage rate, number of unit tests, the evolution of cyclomatic complexity, reduction of technical debt, … ;
• The reduction of the number of defects or at least the number of round trips of the features between development and acceptance;
• The eventual increase in the team’s velocity;
• The implementation of global metrics allows to measure the global optimization: use of the 4 Accelerate metrics (4-key metrics, some can be difficult to implement).

Is there a typical coaching period? Is there a moment when you feel that the coaching should end?

I would say at least 3 months to see the first impacts and changes in practices and potentially in mentality for the people being coached. In general, coaching ends when the team or myself feel that they are autonomous in their learning and continuous improvement. This does not prevent the team from calling on me from time to time when they have questions. 

What are the common mistakes or pitfalls to avoid when doing technical agile coaching?

This job requires a lot of empathy and pedagogy. I would say that it is absolutely necessary to avoid placing oneself as an egocentric knower. During each coaching session, I like to describe my rules of engagement: 

I’m a developer like you, I don’t claim to have THE truth. What we see together is my point of view that I ask you to always challenge.

Have you observed an evolution in the attention companies pay to the quality of their developments in recent years? If so, how do you explain it?

Yes, at least in my sector, there is certainly a growing awareness. I explain it by a constantly changing technological context and increased competition that pushes companies to go fast by taking many shortcuts (not investing in testing, not training their teams, taking shortcuts in terms of architecture) that are costly in the short term: decrease in velocity, increase in the cost of implementing new functionalities, loss of customers…  

The term “Coach Craft” comes up a lot, does it refer to technical agile coaching in your opinion?

From my point of view, it’s the same thing. I would go even further and say that in the context of development teams, so-called agile coaches should actually do technical agile coaching. I would only call on coaches who can accompany teams both on their framework and on the quality of what they produce to deliver maximum value. 

What would you recommend in terms of resources on the subject?

There are a few best-sellers I would gladly recommend:

• “Technical Agile Coaching with the Samman method” by Emily Bache
• “Training from the Back Of The Room” by Sharon Bowman
• “Code that fits in Your Head” by Mark Seemann
• “The Pragmatic Programmer: From Journeyman to Master” by Andrew Hunt and David Thomas
• “The Software Craftsman” by Sandro Mancuso
• “Clean Code” by Uncle Bob
• “Implementing Domain Driven Design” by Vaughn Vernon
• “Fundamentals of Software Architecture” by Mark Richards and Neal Ford
• “Domain Modeling Made Functional” by Scott Wlaschin

 I’ll stop here or I’ll type dozens more 😉 .

Do you have a blog, meetup, or other to follow your activity?

I feed a Knowledge base with my latest workshops. I also host the Craft Luxembourg meetup that I invite you to visit. We try to have at least one event per month.

Thanks! 🙏