Help developers raise the bar: Alexandre Cuva

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

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*).

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

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.

What are the initial issues of the clients and the goals that are set for you?

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.

According to you, are there skills (soft and hard) needed to perform these missions

Yes, as I mentioned above, it is important that the technical agile coach has not only a technical background, but much more than that:

• Practice and knowledge of different TDD, BDD, Pair programming, Mob programming, hexagonal architecture…
• Knowledge of the different practices of understanding the need, like Impact Mapping, Story Mapping, Event Storming, Domain Storytelling, DDD, Specification by Example
• Practice and knowledge of continuous integration, continuous delivery, DevOps
• Practice in facilitation, mentoring, “From behind the classroom” training
• Have at least started professional coaching training; in my case, I have started to follow the systemic coaching ORSC, which I hope to continue as soon as face-to-face training is possible again.
• Be able to communicate with teams, management, and even the top management. You need to be credible at all levels.
• Understand and apply systems thinking, and how a team functions, for example, I often refer to the book “The 5 Dysfunctions of a Team” by Patrick Lencioni.

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

Yes, I work in half-day sessions per team. For most of the teams I follow, the session goes as follows:

• Retrospective on what we observed, heard or learned during the previous session
• 30 min max of theory
• Rest of the session in *Mob Programming* format:
  • Kata
  • Production code
  • Workshop
• Small retrospective on what the team felt and observed

What are the conditions for a successful coaching mission?

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.

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

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.

Can you tell us in a few words what “Organisation Relation and Systemic Coaching” is

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.

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

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.

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

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.

What other daily challenges do you face?

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.

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

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.

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

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.

Have you observed an average coaching time at which you start to see an impact?

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.

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

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.

Have you seen an evolution in the profiles of new developers starting in this profession compared to 10 years ago, for example?

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.

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

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?

You can follow me on my website https//www.socraagile.ch or follow me on my Linkedin account which is much more active.