Hi, I am an organizational coach and Agile Technical, I help organizations decrease their internal complexity by moving to a simple structure that is easily scaled. I work with IT teams to adopt modern development practices, but also collaborative thinking and shared responsibility.
I have a long history of over 25 years of experience, from being a developer by passion, to a professional developer, I started my programming education at the age of 12, with Basic, Assembler and Pascal. I got my first programming certification at the age of 15, and since then I have been practicing different languages, like Perl, Fortran, Modula 2, Java, C#, Kotlin, Python, Elixir, Elm and Typescript. I have been an architect, XP (*Extreme Programming*) evangelist, trainer, Scrum Master, Product Owner, CTO, CEO and today an Organizational Coach and Agile Technical Coach (what used to be called *XP evangelist*).
Technical Agile Coaching is the ability to guide teams on modern development practices, but not only. You need to be able to transform these people into a team that collaborates with common goals and is able to continuously improve. This requires not only a strong technical background, but also a background in facilitation, professional coaching, mentoring and training. I like to say that you don’t have to bring practices on a golden platter, but you have to make sure that these people understand the why and the how on their own. Otherwise it will go in one ear and out the other and when the coach leaves, everything falls away.
It depends on who you’re talking to, but there’s often the same root problem.
If I’m talking to someone in a corporate leadership position, they would like their teams to be able to produce faster, but everything is getting slower and slower. Despite adopting an Agile practice, Scrum for example. The definition of “Business Agility is the ability of an organization to adapt to the market environment quickly.” Nevertheless, the real speed is that of the slowest unit, and often we find applications with a technical debt that is no longer controllable.
If I talk to architects and CTOs, they have a goal of improving quality, better control of applications through best practices. But even if these people progressively adhere to values such as “Craft“, they have neither the time nor the knowledge to transform their teams.
For these two types of interlocutors, the ultimate goal is already the improvement of customer feedback, a happy customer makes the management and development teams happy, and this satisfaction helps us in our productivity.
Yes, as I mentioned above, it is important that the technical agile coach has not only a technical background, but much more than that:
Yes, I work in half-day sessions per team. For most of the teams I follow, the session goes as follows:
You necessarily need the support of the management, who will accept that his team does something else than only producing code or documents. In my case, I only ask for half a day a week!
And of course, you don’t need teams made up of only reluctant people.
In Technical Agile Coaching, as the name suggests, there is coaching only if the people involved agree to be coached.
Yes of course, as I said above, I am currently training in “Organisation Relation and Systemic Coaching”, and I also use books such as those of Alain Cardon and Kathy Anderson on Polarity Coaching.
I also use my knowledge in event facilitation and the “Training from back of the room” method.
The best is that I give you the description that can be found on their website:
The ORSC program proposes a paradigm shift in the way we think and feel, act and react in different circumstances and relational dynamics: in business, in families, in educational settings and more generally in communities around the world.
Based on 7 methodologies – Systemic Thinking, Process Work, Organizational Development Theory (ODT), Family Therapy, Alternative Conflict Resolution, Quantum Physics and Co-Active Coaching – ORSC programs advocate change through the conscious and responsible engagement of people and their relationships.
Currently, I focus on the format shared by Marco Consolaro and Alessandro di Goia of Alcor.Academy, which I joined in November 2021. It is based on the “Training from the back of the room” format. The key is for participants to discover best practices through practice. The session is a mix of training, facilitation, and mentoring. It is a format that I like very much, I currently have much better results than in other approaches I have implemented in the past.
The rule in every change management is not to force people as long as they are not a nuisance to others. We will use the power of decision models. When you see that your colleagues start to adhere, to talk about it in a positive way to others, sooner or later, you will put your ego in the pocket and start to be interested. The last thing you want to do is waste your time trying to change someone who doesn’t want to change.
Now, I’ve given someone a complex problem to do without applying TDD, then I let him do it his way and finally I show him how I would have done it with TDD. There’s no doubt about it, I’m faster.
When the organization is not ready to give the teams some time to improve, we systematically have developers on incidents or other requests during the coaching session. Yet these are sessions that we have planned in advance, there would be the possibility to find other people to solve the problem.
Directly no, but indirectly yes, as in every coaching mission, we work on the individuals and the team. This cannot be measured directly. We will rather measure the level of satisfaction, the number of features delivered over an average period, etc.
There is not really a typical duration of coaching, we work with humans, not machines. For example, for the TDD program, the learning is done in 3 modules of 6 half-days. The DDD module that I gave last year was also 6 half-days.
After these modules, I often offer coaching to make sure that what they have learned stays and lasts.
So I think it takes between 6 and 12 months, knowing that I am never full-time with a team.
And yes, you can feel it when a team can take off without the coach, it’s very rewarding for me and it’s time to go.
Don’t be afraid to say when you don’t know something, you’re a human and you work with humans. Sooner or later it will show if you talk about something you don’t know. When you explain something, it is your opinion, not a fact, otherwise, you have to show your sources.
### **What made you want to start this type of activity in your career?**
Very early in my career, I liked to share my knowledge with others by giving technical training, by being an XP Evangelist (an old term from early 2000). I have also been a speaker at international conferences for over 10 years and co-founded several Agile and Software Crafts communities.
We are seeing many companies that have a strategic goal of embracing the digital world and being more competitive in this VUCA (Volatile, Uncertain, Complex, and Ambiguous) world. These business leaders are promised an acceleration of their ability to respond quickly to these changing environments. True on paper, but in reality, the organization’s real speed is the slowest in its system. Imagine an “eagle with a lead in its foot”, it may be a fast bird, but with a lead, it doesn’t move any faster. This lead is often the IT department and all its software history.
As a result, on the one hand, you have management that doesn’t understand why we’re not moving as fast as we’d like, and on the other hand, an IT department in burnout mode that doesn’t know what to do to get out of it, due to a lack of resources. Of course, the adoption of agility and/or DevOps helps, but it is often not enough, because the core of the problem has rarely been addressed. We have just prepared for the aftermath, but what exists remains.
Many IT managers are precisely the people whose mission is to implement modern development practices. But many of them don’t have the time or the patience to do so. That’s when people like me are called in to ask for their experience.
I’m starting to meet young developers who know modern development practices, which was very rare even 10 years ago. There are a lot more people coming to community events on the same topic.
I am not surprised that we come across the term Coach Crafts, but I find it already outdated, since 2020, we talk about software modernization, it’s much more than just Software Crafts. We are also talking about company culture, team culture, crafts, DevOps, Agile, understanding the need. This is for example the path that a part of the Crafts community has decided to follow. When I read the French-speaking posts on Crafts, they are often limited to technical subjects.
I think they want to limit it to a community and this is already contrary to the philosophy behind Software Crafts.
Do you have a blog, meetup, or other to follow your activity?
Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition