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.
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.
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.
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.
There are 2 main phases in the missions I lead:
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition.
Crafted from Bordeaux, France.