Why our Dev Exchange is one of the best things we ever started in our Product Development

We revived our dev exchange / dynamic teams program last week. I’m not going to get too far into what we do and how we got the idea to do this because we have written about this before when I did my first one, but basically, a dev from one team can spend some time in another team in order to learn something specific, exchange some knowledge and improve our work together. I’ve done this twice before by joining my current team for 1 or 3 days when I was in my previous team. This time, it’s again been someone from my previous team joining my current team, for a week.

Since I’ve now been part of this exchange 3 times, I can now comfortably say that this is the single best thing we ever started in our department and these are the main reasons why:

Inspiration for your own team: 

The person who goes into the other team can take so much inspiration from a different way of working back to their team. That can be little things like using Slack for meetings calls because you can draw on a shared screen or bigger things like how a meeting is structured or how the general sprint workflow is organised in Jira and GitHub.

Outsider’s view on the team workflow: 

The team gets an outsider’s view on their way of working. That can be reassuring and/or it can highlight problems the team itself would have never been able to pinpoint because they are too close and have been doing it like this for a long time.

Understanding your own application better: 

Pairing with someone who is not used to your code and architecture forces you to think about why you do certain things and how they are done which can lead to understanding your own application much better. You cannot just use all the magic that someone has implemented to make things easier, you have to look at the behind-the-scenes code to make the other person understand what you are doing. And this helps you understand better what’s going on and how to use it in different ways.

Understanding both teams’ applications and the interfaces better: 

Explaining the whys and hows leads to an exchange about how these things are done in the other team and usually both parties then find something to improve in their own code and application structure or their understanding of it, and it might even lead to a talk about the interfaces between the two teams and how these can be improved.

Learning about your own way of working and its problems: 

Pairing with someone you don’t usually pair with lets you learn a lot more about your personal way of (and problems with) testing and coding than pairing with someone who’s way and style you have been influenced by. They will ask different questions that can lead you to understand where you should focus your learning on.

Improving informal communication: 

Last, but certainly not least: A lot of knowledge, inspiration and a feeling of togetherness (which is crucial for developing a software product together across teams) is gained from informal conversation. This lets you have coffee chats with someone you might not usually talk to a lot. Especially when everyone is stuck at home, informal communication between teams doesn’t just happen naturally, so an exchange can help a lot with that.

I have explained these things from my personal point of view in more detail on my personal blog.

Our conclusion

Changing teams for a short amount of time and working with someone from outside your team helps both teams improve their way of working, both structurally and technically. It also improves formal and informal communication between the teams.