Philippe Bourgau brings us in his daily life of technical agile coach !

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

Hi Cedric! I am a technical agile coach. I currently work at Murex. I help teams achieve a more productive and sustainable rhythm. I went to school for aeronautics, but I immediately started working in development by passion. I’ve been a developer for 16 years, always incorporating more coaching into my work. It is now the beginning of 2022, and I have been an official coach for four years.

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

I would take Kent Beck’s “why”: “Allow developers to feel safe in this world,” and add my own twist: “Show them another, a more sustainable way”. In other words, I am a technical coach to “Help developers discover a more efficient, calm, and sustainable way of working in this world”.

In practice, I intervene with development teams to guide them on agile development techniques, such as TDD (Test-Driven Development), but also pair and mob programming, collaboration, incremental design, team conventions…

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

A coach often has two clients. The first is the client who finances the mission or the company that directly hires the coach, and the second is the team members who will be coached.

The first often expect more productivity, fewer bugs, or the improvement of other visible short-term team performance measures.

The second ones have much more varied, personal, and sometimes hidden objectives, and the coach discovers them when he starts his mission. Most of the time, it is imperative to move forward on the goals of the second ones to reach the objectives of the first ones in a sustainable way.

An organization (a team or a company) is a system, and it isn’t straightforward to set precise results objectives. I prefer to use experimental goals based on a hypothesis; here is an example:
Hypothesis: We believe that coaching the team on incremental development techniques on their own code
The following objective: deliver earlier while reducing the number of bugs in production
We will be able to validate our hypothesis when the bug rate decreases
We will evaluate our progress on this experiment by the umber of sessions we do with the team and their evaluations of the sessions.

I have written more about this topic on my blog.

In your opinion, are there any skills (soft and hard) needed to accomplish these missions?

The job of a technical agile coach is at the crossroads of many disciplines: development, architecture, agility, change management, coaching… This is one of the aspects I like most about this job. Here are, for example, the main skills I had the opportunity to use:

• Agile development: TDD, pairing, mobbing, refactoring, incremental design, legacy code…

• Architecture: architecture and design principles, DDD (Domain-Driven Design), testing…

• Agility: facilitation, continuous improvement, servant leadership…

• Change management: intrapreneurship, workshop construction, gamification…

• Coaching: listening, identifying the right questions, conflict resolution…

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

As a team coach, I was with the team 100% of the time in my past. This is an interesting position since you stay in the center of the action and have a local but strong and long-term impact. In this case, a typical day is a developer’s day, spending most of the time peer-programming.

Now that I’m officially a coach, I’m no longer spending 100% of my time with teams. I lead code katas with some of them, mob sessions with others, or specialized workshops. In my current position at Murex, we have created a team of part-time technical coaches, who are developers who help us coach the other teams. We spend one day a week with them to train them to coach. In addition to these activities, I also imagine extending our practices to other teams in the organization or creating new workshops to address the latest issues raised by the teams. So no, I don’t really have a typical day, just a mix of these activities.

What are the conditions for a successful coaching mission?

Change is a complex problem, and by definition, there is no guaranteed recipe for success! You have to experiment and adapt. However, I have identified a few parameters that greatly facilitate or block my coaching approach:

• Team members must be willing and eager. Inflicting help is counterproductive, frustrating, and makes change more difficult.

• We need influential technical leaders on our side. There are some in every organization, and it doesn’t have to be the high-ranking ones. If they support coaching, then half the job is done!

• We need to help people solve their problems rather than trying to apply a framework or a method.

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

I draw my inspiration from various sources. As I said above, I rely a lot on experimentation and adaptation.

In this sense, I try to propagate practices as we do for innovation, like a startup.

This leads us to do marketing and sales 😲! My colleagues and I conduct interviews with team members to understand their problems and then identify what we could bring them. This allows us to make a ‘pitch’ to gain their buy-in. This allows us to start the coaching with a clear focus, a tailored objective, and desire.

Finally, we have many sources of inspiration for pedagogy: sport and deliberate practice, “Training from the back of the Room”, Montessori pedagogy, gamification…

Do you have an example of gamification in practice in this technical agile coaching context?

Here are several concrete examples:

• Leading the eXtreme Carpaccio workshop (https://github.com/dlresende/extreme-carpaccio) ;

• Running a Sonar bug fixing competition over several days or weeks, with a small prize ;

• Some C++ developers at Murex also organized a similar competition to fix warnings that prevented from migrating to the latest version of C++ ;

• The “built-in quality game” is a board game that allows one to play with agile development practices and see how investing in quality increases productivity. I want to do an online version!

• I have successfully introduced exploratory testing by transforming the activity into a competition in the past, and it was very effective in turning programmers into extreme testers.

My fellow coaches at Murex and I also have some prototypes in the works:

• TCR (test && commit || revert) has by nature a ‘poker’ aspect where you bet on your code. We think we can push this further by counting points according to the number of small steps, the number of times a test fails… (https://github.com/daviddenton/refactoring-golf);

• We plan to experiment with a Sonar dashboard (or other) to display the quality level of the code of the different pairs of programmers during a kata session;

• Alex Bunardzic, another technical coach, told me about a practice of “Mutant-killing mob session”. The idea is to launch mutation testing on a part of the code and do a mob session where the game is to kill all the mutants!

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

Absolutely. Here’s what my team and I are doing at Murex:

• We start with Code Katas. We vary the formats (pair, mob);

• We then do application mobs. For example, if we have practiced the Strangler Pattern in a kata, we will practice the strangler with the whole team, in mob, on one of their code parts;

• We also use workshops that we build specifically to solve problems related to the whole team. The idea is to integrate all the profiles to rely on collective intelligence to find solutions. For example, we often do a “Test Strategy” workshop, which aims to align the whole team on the management and evolution of their way of testing;

• We have been experimenting more and more with self-service coaching for some time. The idea is to allow teams who don’t necessarily want to see a coach to start changing on their own. This would also allow us to free up time to intervene where we have the most added value. Here are some examples of our experiments:
  
  • We use TCR (test && commit || revert) as a tool to make katas more fun and to encourage participants to break programming into even smaller steps ;
  • We try gamification as much as possible (e.g. Extreme Carpaccio kata, TCR again, but we also have in mind to add scoreboards in the katas…);
  • Finally, we are trying to make our workshops reusable via Miro so that everyone can do them without necessarily being present.

You have written an article on the Samman method from the book by Emily Bache. Can you summarize the overall idea of this method?

This book is an excellent presentation of the technical agile coaching profession. The book contains a guide for the developer or the coach who would like to become an independent coach. But most of the book presents the Samman method. It consists of a few key elements:

Mob programming sessions with the whole team, in a relatively concentrated way over three weeks. This allows the coach to give a lot of messages, feedback, and practices to the team;

These three weeks are followed by three weeks of ‘break’. This allows the coach to breathe and the team to have time to apply what they have learned. After the three weeks, the coach can join the team again;

As part of the Samman method, the coach also leads daily one-hour sessions, open to all: “Learning hours”. These mini-courses use the “Training from the back of the room” format and target a specific technical topic.

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

• I have already mentioned this point in the conditions for a successful coaching mission.

• We only work with willing teams! Otherwise, it’s a waste of time;

• We conduct interviews with the team members to understand their problems and fears;

• We prepare and present a proposition to answer their problems and get the whole team’s adhesion. A typical consultant approach… that works!

• However, after the coaching has started, we sometimes realize that some people are particularly reluctant. If it’s just one person and they don’t have too much influence, the problem often solves itself when they see the improvements that coaching brings. It is more complicated if there are several people or if they have influence. In this case, I have learned to quickly discuss with the person(s) one-on-one to try to understand their needs and see how to collaborate constructively. Sometimes we end up stopping coaching without hope rather than exhausting ourselves and generating frustration on both sides.

Since change is a complex issue, we have to admit that we don’t control all the parameters, and sometimes it doesn’t work!

I have written about this on my blog.

What other daily challenges do you face?

Three major difficulties immediately come to mind:

1. Developers are all too busy! In the modern world, a developer’s man-hour is worth its weight in gold, so it’s challenging to get time for developers to learn to work differently.

2. In 25 years, agile has gone from eXtreme Programming to SAFe. That is, from a subversive practice that emerged from the developer community to a discipline pushed by companies and product managers. Along the way, we lost the developers, and we often encounter resistance from developers who do not all see agility positively.

3. Finally, measuring our impact as a coach doesn’t remain easy. So many other parameters come into play (for example: new deadlines, turnover, legacy code, legacy bugs…) that it is impossible to differentiate what is the result of our work from what comes from other factors.

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

We set coaching goals with the teams and ask for feedback throughout the coaching process to ensure it meets their expectations.

• I apply the objective format I presented above to myself. It allows me to separate my hypothesis about the system from my action, and it makes things clear to everyone from the beginning and allows me to adjust if I see I’m going the wrong way.

• As I said earlier, we only work with volunteer teams. They pay us with their time! If they don’t see the value in our coaching, they can stop at any time. The fact that they continue, ask for more, or recommend us to other teams is a strong indicator of the value of our intervention.

Finally, we must admit that measuring our impact is almost impossible, and Henrik Kniberg describes it in Confession of a Change Agent. He measures his impact by the smiles he receives when he enters the team’s open space.

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

We do not have a typical time period, and in general, it takes a minimum of three months to start seeing the effects.

Not all coaching interventions have the same intensity, and we try to adapt to the teams’ rhythm. Some teams prefer to see us for only a few hours per sprint, and others would like to see us every day!

It is also good to have breaks, let the teams assimilate on their own, and let the change happen.

After a while, the teams become transformation ‘allies’ rather than customers, and the relationship is reversed! They are then the ones who help us build new tools and promote us to the other teams.

Since we are not 100% involved in a team, there is not much risk of dependency.

On the other hand, you have to know how to get out of coaching that becomes unproductive. Despite our precautions, it happens that we find ourselves in a situation where our action has become useless. You have to know how to say stop at that moment. This implies that if you are an independent coach, you have to feed your network to get out of an assignment, find another one, and why not find another coach who might be more compatible with the team.

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

It’s very variable. It depends a lot on where the team is starting from: state of the code, technology, practices in place, mindset. Here are some of the answers:

The impact is exponential. It is slow at the beginning but accelerates afterward;

The fastest effects are on collaboration and team mood. Three weeks can be enough;

In a difficult context, with a lot of legacy code and little test coverage, it can take six months to start seeing gains in team performance;

On the other hand, over the long term, in 3 years, I have seen teams go from very complicated situations to examples of performance and well-being!

What are the common mistakes or pitfalls to avoid when doing technical agile coaching?

To summarize, I would say that the main pitfall is not to accept the complex nature of change management. In practice, this translates into the following three mistakes, which I, unfortunately, fall into more often than I would like:

1. Giving ourselves goals that are out of our control. For example: Wanting to transform the organization or the company: Wanting to make employees happy

2. Stubbornly sticking to our initial plan and not changing it when it doesn’t work;

3. Not stopping early enough when the coaching is unproductive.

What made you want to start this type of activity in your career?

I really believe in what I do. I fell into eXtreme Programming early in my career, and it changed my dev life:

• I worked very little overtime in 16 years as a full-time developer, even as I worked on the trading floor. So I experienced early on time-saving and quality of life benefits generated by this practice;
• I remember implementing new connectors to market interfaces (finance) without bugs!
• I was able to go to the movies without stress on production nights, at a time when production releases were done on weekends and were followed by a planned “post-release” phase (e.g., fire-fighting);
• I was able to accommodate last-minute spec changes without blaming the product managers!
• I’ve seen juniors learn more in 3 years in an XP team than others in 10.

Other developers who have gone through XP have told me the same thing. Once you’ve had a taste of it, it’s tough to go back. That’s not to say it’s easy, XP takes time to master, and you have to overcome many mental blocks. But it takes away 80% of the stress of being a developer.

It’s a job that allows me to “Show another way of working to developers, more sustainable and safer”. As I said above, it’s a job that associates a lot of interesting subjects. Finally, when you are a developer, users are often far away, while technical coaching allows me to be in contact with them every day!

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?

The biggest difference I’ve seen comes from security constraints, and the customers’ requirements push companies to act upstream on quality.

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

Unfortunately, I have not seen a noticeable difference. They still teach the ‘get it right the first time’ technique in school. Companies are now recruiting on a whiteboard, with no testing, no possibility to do incremental development, and no right to make mistakes. Finally, with the number of junior developers increasing exponentially, best practices are unfortunately rarely taught to new entrants.

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

I think these are synonyms for many people.

Personally, I wouldn’t say I like the term Coach Craft. The term “Crafter” is overused, and it seems to have become a synonym for the developer.

I understand the intent behind Software Craftsmanship, but I find it separates the development from other aspects of the team. XP integrates all this diversity into a coherent whole.

In my opinion, technical agile coaching is about coaching teams to become more agile by integrating the technical prerequisites (for example, the division into stories). In contrast, coach craft only reminds me of coaching dev practices without context. On the other hand, it is possible to coach developers to agile principles through katas! Technical agile coaching is agile coaching via dev techniques, not agile dev techniques coaching!

What would you recommend in terms of resources on the subject?

If I had to recommend only one, it would be The Art of Agile Development by James Shore. It’s a complete reference that gives an overview of the subject and that I regularly read.

Otherwise, here is a short selection:

• The first edition of XP Embrace Change by Kent Beck. It is unfiltered, not always politically correct, and for me, it is the purest expression of what agility is all about;

• Refactoring by Martin Fowler contains everything you need to know to do incremental design. I often see this book in the lists of books to read, but finally, few people have read it;

• Mob Programming by Woody Zuill, a must-read for what is for me the most important update of XP in 20 years;

• Emily Bache’s books Coding Dojo Handbook and Samman Technical Coaching are outstanding books for someone who wants to start coding dojos or technical coaching.

After that, the list is too long! Technical agile coaching is diverse enough to draw from almost any field.

Do you have a blog, meetup, or other to follow your activity?

Yes, I regularly blog about technical agile coaching on https://philippe.bourgau.net. Whether you are a technical coach or a developer looking to bring about change, this should be interesting for you.