At Container Solutions, we often develop advanced Cloud Native solutions and cutting-edge technologies with our customers. There are many challenges with this work. One of them we encounter often is getting everyone on the team on the same level of understanding and engagement.
Recently, our team was helping one of our German customers develop a CI/CD provisioning platform based on Kubernetes operators. Some members of our client’s team of engineers, however, were not happy about that. They were missing context, knowledge, and experience to work on a project that required a lot of development and experimentation with brand new technologies.
In order to bridge those gaps, we started a ‘pair programming’ initiative to get everyone on the same level. Here’s how we did it.
Help On-Demand
To start our pair programming effort, we virtually ‘divided’ the team into two groups: people who were very experienced with Cloud Native Technologies, and people who would need knowledge transfer on those technologies. In the first step, we’ve let the Cloud Native-experienced engineers show how the inexperienced team members can solve problems, and continue developing on their own.
Within this challenge lay others that made the job more complicated. Our Container Solutions team was distributed across six different locations in Europe and Canada. All the programming sessions had to be conducted online and on-demand, depending on the location and time availability of the team members.
Sometimes, problems have arisen dynamically during the sprint. One of the team members would then ask for help during daily Scrum meetings and some of the Cloud Native ‘experts’ would jump on the pair programming session with the person who needed assistance. Sometimes we’ve also run ‘open’ sessions, where everyone could see and listen to what an ‘expert’ in the team would present.
This has helped us jump over the first obstacle: getting everyone to have a basic understanding of the architecture and technology that we plan to use. People started to show this by engaging more in the smaller design discussions that had to take place as well as by coming up with their own solutions to challenges that we faced along the way.
Speaking Up, Turning Down
As the project progressed, the client team members’ levels of experience and engagement still varied a lot. There were people who would not speak at all during some of our meetings—and some people spoke a lot.
As it turned out, some people felt more comfortable speaking German than English. Over time we have noticed that the language barrier might have been the reason why some of the team members were not that active during design sessions.
At Container Solutions, we speak English in our offices—it is, after all, the language of international business, and our staff comes from all over the world. But for many of us, it’s not our first language. We have an office in Berlin, and several engineers on the team working with this German client also speak German.
So to help our client’s engineers scale the language barrier and participate more in the discussions, we started some new initiatives. We started encouraging people to speak German, when they could not find proper words in English. This helped a lot: People felt more comfortable expressing their ideas in their native language.
By contrast, sometimes fierce discussions erupted between some of the team members who were very active in the group. In order to make space for others, sometimes we had to step in.
If we saw someone struggling with interrupting during a long discussion, we would then amplify his voice by saying something like, ‘Hey, I think so-and-so wants to say something’. This way, we have kept each other in check and made sure no one takes over the conversation.
In the Driver’s Seat
Our next step in helping our clients’ team was letting less experienced people take the driver's seat. When someone would have a problem, two people would get together on an online call, but the less experienced one would always lead the coding and the most experienced person would only give hints and tips.
This technique also turned out to be very effective, as people started getting up to speed with code intricacies and understood many details that were unknown to them earlier. People felt elevated and started to engage more and more in discussions, design sessions, and retrospectives.
I think this was a very successful endeavour. We connected on a totally different level, and we feel more like a one team now.
This was a long journey that has spanned six months of the project, but it’s definitely not the end of the road. It takes a lot of time and effort to pair program and learn Cloud Native technologies. We advise companies to use it wisely and be prepared for some setbacks. Be patient.
We’ve got clear verbal feedback after a few sprints that team members were much happier and understood more than before the pair programming and other initiatives began. However, you should make sure to monitor the situation and adjust as you go. What worked for us might not work for you.
Previous article
