How to foster technical interactions with other teams of developers?

Software development teams structure and organization affect their efficiency and their productivity. If you have several software development teams in your company, maybe you’ve already heard:

“Our teams don’t talk to each other”

This situation happened more than once with our customers at Packmind. Companies have brilliant engineers in their teams that work on complex challenges every day. Still, sometimes they feel frustrated because they lack interactions, which are missed opportunities to learn from each other and grow their skills. Many reasons can explain that: teams work every day on their own tasks, must complete their sprint (what a weird name, btw, don’t you think? Who runs to work?), so it can be hard to find slots for technical interactions. Let’s discuss four practices you can use to boost knowledge sharing and technical discussions in your organization.

#1 Coding Dojo

Coding Dojos are collective programming exercises. They have an educational purpose, such as practicing Test-Driven Development, or getting familiar with a particular programming language. Collections of exercises for Coding Dojo are available online, including at codingdojo.org. There are two main formats for Coding Dojo:

• Kata: One person holds the keyboard and demonstrates the exercise, taking the time to specify the points needed for the participants to understand it step by step. This person has already mastered the subject.
• Randori: The resolution of the exercise takes place with Pair/Mob programming sessions with a rotating keyboard system. The pairs change every 5 or 10 minutes so that everyone participates. The audience can ask questions but let the pair progress without disturbing them.

Katas will often imply the practice of Test-Driven Development, as the statements of the Dojos are a series of steps to follow, reminding us of the functional increments to add to our software projects. Coding Dojos sessions should be open to anyone, whatever the team they belong. A minimum of logistics will be necessary: preparation beforehand by one or more people who have already practiced the exercise, a physical location with enough room for everyone, and timing to respect: the duration of the session will be fixed in advance (1,5 hours is fair to start), and we will keep a few minutes at the end of the workshop to debrief together. If these sessions are organized during the lunch break, you might ensure that the participants have their lunch with them when the session starts. Coding Dojos are part of the learning process and the development teams’ skills increase. They’re great for technical interactions since they rely on communication, listening, transmission, and sharing.

#2 Communities of practices

Knowledge-sharing in agile organizations has become a significant challenge. Communities of practices gather anyone interested in the topic of the community: data, back-end, security,… These are sometimes informal structures based on voluntary involvement, and they can also be more official if employees have dedicated time for this community. These communities are designed to share knowledge, align practices or make technical decisions regarding the topic of the community. The Spotify model often inspires the organization and structure, including Guilds, Chapters, and Tribes. A guild is the closest form of a community of practices in their context. We advise setting a meeting frequency for these communities so that members can schedule them in their agenda, monthly, for instance. Indeed, a common pitfall for these communities is related to their organization and animation. By definition, members work in different teams, even in separate company entities, and can be located across various geographical regions. Even with a rigorous organization, meeting everyone’s constraints can be tedious. To be sustainable, these communities’ meetings must deliver value to their members. Otherwise, they’ll probably start forsaking these groups. Their schedule can take various forms, among them:

• Sharing feedback and return on experience after deploying a new tool or architectural approach in a project ;
• An external speaker bringing a topic of interest to the community (see below) ;
• Discussing best practices to adopt for all developers concerned by the domain of the community.

You can find even more possible animations. It also depends on your software development teams structure. Don’t hesitate to produce a short meeting report to keep track of any technical aspects discussed. Anyone in the community can then read the report and remember what’s been decided two months ago!

#3 BBL / Meetup

BBLs (Brown-bag Launch, which refers to the brown kraft paper bag that contains our lunch) are talks organized for your internal Tech community. The speaker can either be internal or external (feel free to invite them directly). This is an excellent opportunity for your teams to get familiar with a topic and discuss it together during this session. Having lunch together while talking about technical stuff is a perfect pretext to start discussions and make everyone share how they do in their respective project. One important thing if you invite an external speaker: don’t forget to offer food to your guest! You can also host external communities, such as Meetups (e.g., Java User Group), which are often looking for places for their sessions. This is a great way to get closer to the local Tech community, especially if you’re currently looking for candidates to hire.

#4 Craft Workshops

The Craft Workshops are embedded in the Packmind platform and focus on the definition and sharing of best practices for developers. These sessions happen within a team or a community of teams. The idea is to discuss together our coding practices, let everyone contribute and make suggestions, and then decide what to keep. These sessions proved to be efficient in aligning practices and enriching a knowledge base. Each developer can identify examples and counter-examples of best coding practices before the session, either in their IDE or Web browser (during a code review). Packmind provides extensions for that purpose, so everyone can participate in creating the team’s practices repository. It is important to note that this identification occurs only within the team’s working environment (code review tool, IDE) to have a relevant context. Regularly (usually once per sprint), the team or a community of practice meets by video or in-person to carry out this Practice Review workshop. The objective is to review all the practices identified by developers. Each practice (as well as the associated correction) is then presented, validated or not by the team. During this workshop, it is possible to discover best practices from other teams in the company. This brings transparency and supports knowledge sharing.

To spread these best practices efficiently and not transform the practices repository into an abandoned Wiki, Packmind extensions provide automatic suggestions when practices are not followed in the code, based on what is present in the examples and counter-examples in the practices repository.

What’s next?

We hope this article gave you some insights and paths to follow to increase interactions among your developers’ teams. We saw that software development teams structure can have a strong impact on the knowledge sharing process in your organization. Feel free to add in comments which rituals you’ve set up in your organization, what succeeded, what failed, and why. We’d be happy to learn from you!