Discover Technical Agile Coaching with Jean-Louis Rigau

Let’s discover more about Technical Agile Coaching. We met Jean-Louis Rigau, Technical Agile Coach, who tells us more about his missions during a Technical Coaching session and his day-to-day work in the teams. Agile, Software Craftsmanship, DevOps, we discuss all these topics together.

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

My name is Jean-Louis Rigau, I am 37 years old, and I am a Technical Agile Coach. I have 15 years of experience in software development consulting as a developer or coach.

I have strong expertise in backend development within the Java ecosystem with a strong appetite for quality and everything related to Software Craftsmanship. I became interested in Continuous Delivery and everything that revolves around containers and the Cloud Native environment, both on the platform and application side.

In my career, I had the chance to work with technical mentors who helped me grow, and today, with my coaching approach, I want to pass on the knowledge I acquired through my experience. 

Whether as a developer or as a coach today, I’ve always had the desire to grow and to help others grow both humanly and technically.

Can you tell us more about Technical Agile Coach ? 

More than a job, it is more a mission in which I try to accompany agile and product-oriented teams in their control of their code and their pipeline to make their delivery more reliable.

My role as Technical Agile Coach consists of being immersed in the teams and developing with them the backlog features directly on their codebase. My objective is to help the team become more competent in its practices to make it more autonomous and support the change, which sometimes requires starting by unlearning before relearning.

My approach consists of transmitting best practices, the correct use of tools, and the right culture to give back control to the teams to improve their capacity to deliver and thus their performance.

What are the needs formulated by the client and the objectives set for you? 

Before formulating their needs, we meet the customers first to identify problems they do not know how to answer.

The first difficulties expressed are the loss of control over their delivery (more and more bugs and support that complicate deliveries in Production). These customers are either in the middle of an Agile transformation or have already completed it, yet they cannot deliver more often and with better quality. They realize the need to put the focus back on work practices rather than on work organization.

The second difficulty is related to the teams themselves, who are responsible for the entire delivery chain (Dev to Prod). Due to a lack of competence and sometimes a lack of appetite, they find it difficult to achieve this. The need expressed by clients is to recreate commitment in the teams, to restore passion, and retain talent.

My objectives are generally to accompany an initial team to give them back control over their code and delivery and interest in what they do and then deploy the system on a larger scale.

In terms of implementation, how do your missions unfold? 

There are 2 main phases in the missions I lead:

1. The first phase of observation will allow me to meet as many people as possible within the teams, immerse myself in their daily lives, and understand their problems. The challenge is building a relationship of trust with the teams and establishing an inventory in practice, culture, and tools. It is also an opportunity to identify how team performance is measured. At the end of this phase, I hold a kick-off session to give my report on my astonishment and present the coaching approach. 

2. The second phase is devoted to coaching in immersion within the teams. I may have to coach up to 4 teams simultaneously over periods of 3 to 4 weeks (depending on the rhythm of the team sprints), which will be punctuated by “off” periods to let the team experiment by itself.

What is a typical day like in a team? 

Once the observation phase is over, a typical day consists of being immersed in a team and working.

It is generally structured around Mob Programming sessions with all or part of the team, during which we carry out a feature of the backlog by focusing on best development practices.

Between the Mob Programming sessions, I do some Peer Programming with the different team members to solve the Mob sessions’ problems or deepen certain practices in individual coaching.

I never carry out a delivery task alone.

If we consider the principles of Test-Driven Development, for example, how do you get a team to adopt them and integrate them into its development methods?

Concretely, I will gradually introduce the development practices without necessarily naming them initially. Above all, I want to show things differently (live coding) to whet the curiosity and arouse the team members’ interest by showing them the value of the practices implemented.

Once the interest is aroused, together, we will deepen the practice (naming it this time) and then try to master it. During this stage, I will encourage experimentation by the team members, and I will position myself more as support (Shu-Ha-Ri method).

The challenge is to succeed in integrating these practices into the daily life of the team. It is necessary to implement the practices and factually measure their impact on delivery capabilities to perceive their value.

In your career as a developer, at what point did you turn to this coaching activity? And why did you do it?

At the beginning of my career, I had the chance to work with more senior developers who were real technical mentors for me and introduced me to good development practices. They introduced me to good books: Clean Code by Robert C. Martin (Uncle Bob), Working Effectively with Legacy Code by Michael C. Feathers, etc. They also took the time to work with me in Peer Programming in an Extreme Programming (XP) approach.

Since then, I have always been in search of quality and excellence through my development practices. This search for excellence has pushed me to improve myself to gain control and be more efficient constantly.

At a turning point in my career, I wanted to pass on this passion for helping others grow, so I turned to coach.

What are the technical and human qualities necessary for the missions you carry out?

First of all, what is essential is to have a passion for technique and the desire to transmit.

Fundamentally, you must have strong technical expertise in Craft and Continuous Delivery, whatever the language or technical domain (Dev, Infra, Data, etc.). The experience must be significant and more focused on practices than on tools. 

What advice would you give to someone who wants to become a Technical Agile Coach?

To believe in oneself and above all not to abandon the technical side of things, even if it is still not fully appreciated: today it is possible to make a career in the technical field.

Of course, it is important not to compromise on the development practices and quality of your projects. However, it is often difficult to implement a new practice within a team because its value is not sufficiently visible, leading to abandoning it before having the benefits.

To change this, I advise measuring factually and systematically the impact of development practices on the delivery capacity of the team and to rely on the 4 key metrics (see Accelerate book).

Is it necessary to master certain languages/frameworks to coach a team? For example, if I have never done Python, am I relevant to technically coach a team on a project coded in Python?

From my perspective, it is more a solid experience on development practices that is essential, because the coach will be able to rely on it to adapt to the context of each team.

Mastering a language or a framework is not the most important thing, even if it is a plus for coaching teams that use this same language or framework.

According to you, does being a Technical Agile Coach require a certain level of experience? If yes, which one?

Yes, they necessarily require a significant experience as a developer but not necessarily as a coach, although a strong appetite for transmission is essential.

To be a Technical Agile Coach, you must of course have a strong expertise in Craft and Continuous Delivery practices. Still, without being an expert on all the tools, because as said before, it is above all the experience on the practices that counts.

What are the challenges you face when you join a team?

For me, the biggest challenge I face is to build a relationship of trust with the team. It is essential to fully concentrate on the team’s development when I carry out immersion coaching.

To gain this trust, you must, first of all, demonstrate your ability to both prove yourself and arouse interest. Then, curiosity does the rest. In a team, there will always be one person who has an appetite for the practices introduced and on whom I can rely on gaining the support of the rest of the team.

What kind of welcome do you get from the team you are working with? And how do your relationships evolve over time? 

It varies a lot because the team may be a little apprehensive about my role and what I can bring to the team. Hence the importance of the work done during the observation phase enables us to lay the foundations of a relationship of trust with the teams.

Once the relationship has been established, collaboration comes naturally, and I become an integral part of the team. The team understands that my objective is to accompany them and not to monitor them.

More often than not, things start to click when the team becomes aware of the direct value of the practices introduced in their daily lives. It will then gain control and gradually settle into a virtuous circle of continuous improvement.

The team gains autonomy and will be able to shine within the organization. This is when I become dispensable.

Have any of your clients in the past experienced other alternatives to coaching as you implement it? If so, can you tell us more?

Not many clients have ever used technical coaching because it’s still new and immersive.

I have clients who have already used technical coaches and are sometimes disappointed with the results because of the low impact on the teams’ daily lives and the improvement of the delivery.

In my coaching approach, I focus on the teams in order to have a visible and real action on their mastery of the code and their delivery capacity. We are in a bottom-up approach that allows us to have systemic impacts on the organization.

Today, clients are ready to use technical coaching but with high expectations on the results because they want to see a concrete improvement in the delivery capacity of their teams.

Doing Mob Programming or collective review, when a team is not used to openly discussing its code, must generate some fear or discomfort at first.
How do you manage to put everyone at ease? 

When I introduce the Mob Programming sessions, I’m the one who initially does most of the work, which can be similar to live coding. Once interest is aroused, some team members will gradually take over and engage the rest of the team.

Don’t hesitate to give the floor to everyone, including those who naturally take a back seat, in order to get everyone’s opinion.

With your experience and your hindsight, what are the common mistakes to avoid when doing Technical Coaching?

For me, the first mistake is to spread yourself too thin, either by trying to coach too many teams at once or by trying to address organizational problems and the team’s skills development at the same time. One can quickly find oneself flitting from one team to another, which reduces the scope of impact.

The second common mistake is to think that raising awareness and performing Katas is enough to get the team to adopt new practices. It is essential to immerse oneself in the team’s daily life by working with them to enable them to implement the practices directly in their daily lives.

Finally, the most common mistake made when immersed in the team is to find oneself doing delivery tasks alone and thus losing the initial objective of increasing the team’s skills. It is therefore essential that the Technical Agile Coach never performs delivery tasks alone. The challenge is to work with the team and not in their place.

Conversely, what are the key success factors in this type of mission?

A key success factor is to be able to find the relays within the team. Without relays, it will be almost impossible to gain the team’s trust and make progress.

Another key factor of success is systematically sharing what has been learned, both within the team and the organization, thus enhancing the value of the techniques acquired, as there is a real challenge of teaching to demonstrate the value of the practices implemented.

A final key factor is to measure the factual gains brought about by implementing new practices within the team on its delivery capacity and ultimately on its performance.

If the importance of mastering one’s code and producing quality code has always been a major issue, investments and concrete actions have not always been forthcoming.
This seems to have changed in the last few years, at least that’s what we’ve noticed at Promyze.
Do you share this analysis?

Yes, I completely share this analysis. There is now a real awareness among customers of the importance of mastering their code and producing quality code. On the other hand, concrete results need to be reassured, explaining why they are not yet investing fully in the subject.

Beyond the lack of results, clients have difficulty finding the means to improve the skills of their teams in terms of code mastery and delivery quality for several reasons: sometimes a lack of skills, an appetence, or a lack of perspective.

I imagine that you are often challenged on the ROI of your intervention. Are you able to provide some improvement indicators? If so, which ones?

Yes, I am regularly challenged on the ROI of my intervention and indirectly on the benefits of the Craft and Continuous delivery practices. This is because these practices do not bring immediate value and are also difficult to measure.

Today, the indicators that we measure are mainly related to either the quality of the code or the teams’ maturity and do not really reflect the teams’ performance.

In my coaching approach, I focus more on measuring the ability of teams to deliver rather than the quality of the code or the team’s maturity. In particular, I use the 4 key metrics (The State of DevOps / Accelerate), which are more relevant indicators to measure the value of the team’s mastery of code and delivery on its performance.

How do you see your job evolving in the next few years? Do you think it will tend to become more democratic?

I already see an appetite for technical coaching among more and more clients and what is interesting is that it is perceived at its true value because of its stakes and the expected results.

For me, it is clear that the need for teams to master their code and their delivery exists and that the demand for coaching will grow accordingly. So there is a real need to democratize technical coaching to meet this need.

You recently discovered Promyze, our tool to help define and spread best practices. From our perspective, Promyze supports the work of coaches whose mission is to align practices within a team and capitalize on this between different teams. What is your point of view on this?

I discovered the tool by chance while researching technical coaching, and I immediately wanted to try it.

As a technical coach, when I arrive in a team, I need to quickly demonstrate the implementation of practices, especially around Clean Code, and what I found great about Promyze is that it allows me to have code snippets at hand that I can show to the team and that will also allow me to bootstrap an environment faster.

It is both a tool for capitalizing on the knowledge and, above all, for sharing with the teams and between coaches. Recent integrations with IDEs make it a real companion for the coach by becoming part of his daily life.

What are your short-term projects?

In a 3 to 6-month time frame, my ambition is to :

• Communicate both around this new role of Technical Agile Coach and the immersion coaching approach to democratize them.

• Increase the number of clients who trust us and whom we coach

• And of course, to recruit!

Find more on Jean-Louis Rigau  :

• Twitter : https://twitter.com/jlrigau

• Linkedin : https://www.linkedin.com/in/jlrigau

Like Jean-Louis, you are a technical coach and you would like to discover how Promyze can support you during your missions? 

Are you attracted by the idea of improving your development practices as a team? Do you want to gain in excellence and technical mastery? 

Tell us about your project!