Help developers raise the bar: Alexandre Cuva.

Alexandre Cuva -

This post was originally posted on Promyze Blog post on 22 February 2021 under: https://www.promyze.com/alexandre-cuva-technical-agile-coaching/

Hello Alexandre! First, 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, scaled structure. I work with IT teams to adopt modern development practices, collaborative thinking, and shared responsibility.

I have 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. Since then, I have practiced 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 transform these people into a team that collaborates with common goals and can improve continuously. This requires a strong technical background and 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 must ensure 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 clients' initial issues and the goals 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. “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 aim to improve quality and 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 the improvement of customer feedback; a happy customer makes the management and development teams happy, and this satisfaction helps 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 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
  • I 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.
  • 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 with a team 100% of the time? 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 other, than only producing code or documents. In my case, I only ask for half a day a week!

And, technical Agile coaching, as the name suggests, is coaching. Of course, you don’t need teams of only reluctant people, 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 the 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 seven, 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 I like very much, and I currently have much better results than with other approaches I have implemented.

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 and talk about it positively 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.

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 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 six half-days.

After these modules, I often offer coaching to ensure that what they have learned stays and lasts.

So I think it takes between 6 and 12 months, knowing that I have never worked 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. Explaining something 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 as an XP Evangelist (an old term from early 2000). I have also been a speaker at international conferences for over ten years and co-founded several Agile and Software Crafts communities.

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?

We are seeing many companies with 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 the organization’s 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, adopting 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 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?

I’m starting to meet young developers who know modern development practices, which was rare even ten years ago. Many more people are 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 have talked about software modernization, which is much more than just Software Crafts. We are also talking about company culture, team culture, crafts, DevOps, Agile, and 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, which 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 my Linkedin account which is much more active.