Scaling Software Craftsmanship

In our lastest webinar, we talked about the craft at scale.

We welcomed Aurélien Rambaux, craftsman coach at ManoMano for 3 years, and Julien Topçu, technical coach at Shodo, a software firm specialized in software craftsmanship and Domain-Driven Design.

Aurélien is the only technical coach for 45 teams, about 300 developers. He works with various teams on the ecosystems he knows, which are Java, Kotlin, and PHP, but also on ecosystems he knows less or not at all, which are React and Go. Julien supports customers on acculturation topics such as craft, DDD, Flow, or Application Security.

Why you need a coach in software craftmanship

Aurélien explained he learned things by himself initially, but then some competent and pedagogical colleagues taught him things very quickly and efficiently. When you make a mistake because you don’t know something, you won’t learn if no one tells you it’s wrong. To answer this question, Julien made a parallel: “Why do top athletes need coaches?”. Coaching aims to bring an outside view on what people do, to help them, not just to give them knowledge. A coach is someone with different abilities whose goal is to help them overcome.

Also, a coach is not necessarily technically better than the person he coaches; the coach of Usain Bolt doesn’t run faster than him, as Julien says. For example, he can use the solution-focus method; by raising the issue, the coach can push the developers to find the answer on their own, while the coach himself doesn’t have it. Also, the coach learns from others by seeing how they do and progress. Developers like external points of view that would not come from their hierarchy.

For Aurelien, who coaches 45 teams at ManoMano alone, the strategy is to focus on people willing to progress. “If I work with receptive teams, it goes much faster. Once we start the machine, it goes pretty well” he says. Developing their interest in a subject they do not know is necessary. Thursday afternoons are free at ManoMano, so everyone can learn, with MOOC or Udemy, for example, or with internal sessions. The first hour of these afternoons is dedicated to speeches. Aurelien does it and tries to talk about various topics for 10 minutes to light the interest.

Define goals and problems to scale software craftmanship in your org

According to Julien, to bring people to use certain practices, it is necessary to rationalize these practices to their pain; otherwise, they will be bored to do it and will become detractors. It is impossible to scale up a practice. In a company with more than a dozen teams, each team has a different need and faces a different level of complexity of work. And because the team members are different, they have different strengths and skills.

The best way to get people to change their culture is to show that it helps them, which means taking their specific problem in production and helping them solve it. If you want to do something at scale, you must invest in communication and communication dynamics; the problem is the human aspect, the way people talk to each other. It’s challenging and takes time, but you have to accept it. The craft at scale alone doesn’t work; you need business objectives behind it.

“It is by going to each team in their trench that I can help them where they need it most.”, says Aurélien. Developers do not necessarily come to him with problems, partly because they do not know how to formulate them; that’s why he runs two activities with the teams:

1. He runs Mob programming sessions. Out of 45 teams, he did it with more than half of the teams. It doesn’t work with all the teams (personalities, team dynamics…), but it worked very well for more than half of them; it favors communication within the team, so he stands as a facilitator, but the team itself is starting to formalize the problems it faces.
2. He runs audits; for example, his last was for a team that didn’t know much about Kotlin’s best practices, so they wanted advice. Also, they wanted to design microservices in Kotlin. Once they understood, they didn’t need him anymore and could work alone.

“People learn a culture by facing the exterior. If a team is unaware of its problems, it is because they are not shown, which should be the manager’s job. If they’re not aware of their problem, it’s not only them who fail, but the whole organization and not only coaching will solve it.” highlights Julien.

So, how to spread a culture of software craftmanship?

Remember that culture is alive; it adapts to each company and team. Pollination is the most important; the culture must be shared between teams. In general, we can talk about soft pollination, with communities of practices where people will show from time to time what they have done. The problem is that it’s useless: the ROI is very low because people are not involved when it’s not suited to them.

For Julien, a key point is the flexibility to move people from team to team for a while. Crossing people on concrete cases strengthens pollination. Also, the developers will see something else, have new points of view, and learn. Of course, it has to be voluntary; otherwise, it would be counterproductive. Another excellent way to spread culture is to go and see what is being done elsewhere. For example, by attending conferences, meetups, or hosting BBL. You must be curious to see how others are doing, keep an open mind, and know how to question yourself.

Start sharing your best coding practices

Promyze supports this culture of raising the bar, with a solution to share tailored best coding practices. Within Promyze, teams address topics relevant to them: security, accessibility, performance, etc. It welcomes practices specific to each team and for an organization. The tool provides support for continuously discussing and improving teams’ best practices. It takes part in the overall Craft at Scale strategy.

And you, what are your techniques for spreading your technical culture?

Here is the replay of this webinar. If you don’t want to miss the upcoming ones, register here!