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.
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…
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.
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:
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.
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:
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…
Here are several concrete examples:
My fellow coaches at Murex and I also have some prototypes in the works:
Absolutely. Here’s what my team and I are doing at Murex:
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.
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.
Three major difficulties immediately come to mind:
We set coaching goals with the teams and ask for feedback throughout the coaching process to ensure it meets their expectations.
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.
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.
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!
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:
I really believe in what I do. I fell into eXtreme Programming early in my career, and it changed my dev life:
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!
The biggest difference I’ve seen comes from security constraints, and the customers’ requirements push companies to act upstream on quality.
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.
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!
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:
After that, the list is too long! Technical agile coaching is diverse enough to draw from almost any field.
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.
Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition