Doing Distributed Development well in our Payments Group
Alistair Cockburn, agile manifesto signatory and author of Agile Software Development (2002) wrote about the “bandwidth” of different communication styles. Distributed development forces modes where there is less “bandwidth” and is inevitable in today’s age of more connected and more distributed workplaces.
At N26, we’ve tried to avoid distributing work across multiple locations, preferring to have a topic owned by people in a single location. Although that’s the ideal, there are always exceptions. In today’s interview, I spoke with Sarah Abrantes (Engineering Manager) and Lukas Klinser (Product Manager) who work in our Payments Group where they experienced distributed development.
Pat: Some teams working in the Payments product area are quite different from others because they have a history of doing distributed development. Can you please share some examples of what that looks like?
Lukas: N26 continues evolving as a global company. The Payments Group leads the way for N26, learning from pain points and creating blueprints to do distributed development well. I’ll give you two examples:
- We launched N26 last year in the UK. Payment systems are different in the UK and we had a lot of existing work, so we worked with a team of external consultants in Barcelona to help us launch on time. With our engineering team in Berlin, we developed over two locations.
- We have a feature enabling instant N26-to-N26 transfers called Moneybeam. We wanted to start offering this across all of our markets (EU, UK and the recent launch in the US). This meant moving from two to three locations (Barcelona, Berlin and NYC).
Pat: Distributed across two locations sounds hard enough. I can imagine three would be yet another challenge! What are some challenges the teams faced?
Sarah: Onboarding is a constant challenge. Not only at the start of a project, but also throughout as we’ve continued to grow. Onboarding is much harder in a distributed environment. When you’re co-located, pair programming and asking ad hoc questions is easier. You feel connected all the time. When you’re remote, you need to find ways to constantly integrate everyone. You want to watch out for side conversations. For example, decisions might be made over a coffee break. Those not included will naturally feel excluded from the conversation. We set up practices to keep the conversation flowing as if we were in a single location.
Pat: What are some of those practices?
Sarah: We invested in as many face-to-face trips as possible. This was much easier between Berlin and Barcelona, than say, NYC. When people had face time, they built richer personal relationships. This improves empathy, understanding and communication. People understand each other's personalities better. When you read a message on slack after meeting someone, you can almost imagine it in their voice or tone. This reduces misunderstandings significantly. We also have all team ceremonies online with good video conferencing equipment. We make sure that no official team meetings happens without remote participants.
Pat: Great! I can see how the face-to-face time makes a big difference. OK, so what does a typical day look like? How do people communicate and collaborate?
Lukas: That’s a good question. It makes me think. We all start our day the same way. We arrive at the office and catch up on systems like email, slack or our electronic tracking systems, etc. We usually have stand-ups at around 11:00. When we had teams in Berlin and Barcelona, we’d ask for both sides to do their stand-up in a meeting room in both locations. We would then “walk the wall” during this meeting. We never tried a physical board and it worked well for us. As questions came up during the day, we introduced a practice of ad hoc meetings if messages over slack looked like they needed a longer discussion. We suggested some time slots. People voted with emojis and then people would jump on a video conference. These are our ways of establishing a remote-first team approach to discussions. We wanted to discourage simply turning around and chatting to whomever was closest, as this would exclude many people.
Pat: Yes, I can see that. Let’s talk about tools. It’s a super common question I come across when talking about distributed development. What did you try? What didn’t stick? I already heard about Slack and your electronic tracking tool. What else helped?
Sarah: When we were doing stands up in meeting rooms, we faced a problem many companies have… not enough meeting rooms. Our team evolved to be more efficient. People stay at their desks and everyone attends the meeting remotely. It makes the team space noisier but on the other hand, it means everyone is deep in the meeting. Everyone experiences the same environment and shares the same constraints. You avoid issues where one side feels less included because they struggle with video conferencing for the day. Our room constraint pushed us to try something new, and resulted in a very positive outcome.
Pat: Now everyone is at their desk for remote meetings. Tell me about a person’s physical desk setup? What does that look like?
Lukas: Everyone has a pair of good headphones. Most people seem to prefer over-ear headphones, which they also use for music to get into the “zone”. We encourage people to avoid furiously typing during meetings, and that everyone focuses on the call. We have a remote ally for a week who shares their screen to provide the shared view of our electronic tracking system.
Lukas: When we worked more with meeting rooms, we tried a Meeting Owl device. It solved the problem of many people hunching around a small camera or to get closer to the speaker. The Meeting Owl takes a 360 view of the room and always focuses in on who is talking without any additional software. That was very helpful.
Sarah: We also experimented with some remote pairing tools but due to our risk analysis, we stopped using them. Security is our top concern, so we had to make a tough call and stop using such tools.
Pat: Your teams developed distributed for some time. Are there practices that you tried, that stopped working? What did you try that didn’t stick.
Sarah: We stopped remote pair programming because of the tool constraint. It was a showstopper. We moved to co-located pair programming and cross-office reviews.
Lukas: I can’t think of any other things. We quickly found ways that worked. If we feel pain points, we try to solve them very quickly.
Sarah: I think our focus on transparency and team culture helped here. In the past, we had speedback sessions so team members could swap feedback. It’s hard to detect when individuals have issues between them and our speedback sessions helped build this learning culture.
>> Speedback sessions are very short feedback sessions involving all team members, in which they share a short feedback with a peer and move along to do the same in a different pair. Much like a speed dating.
Pat: Let’s talk about one of my favourite topics: Retrospectives. How did that work in your situation? What worked well for your team?
Lukas: Software worked for us, essentially. Normally you would gather in a room, you’d have a facilitator and hand out post-its and pens. Then you would think about what works well, what didn’t go so well, discuss, etc. Since we didn’t have that we needed to find an equivalent. We found a tool that would allow us to mimic that same behaviour where you can have different columns and allowed people to anonymously add contributions.
Pat: Who was facilitating and how did that work? How did you synchronise people in different locations?
Lukas: We usually rotated facilitators between locations. Sometimes we had people outside of the team which worked very well. When we had more independent facilitators, team members could really focus on taking part in retrospectives.
Pat: Imagine you’re sitting in front of another team, who’s about to go on their own distributed team adventure. What advice would you give them?
Sarah: Remember that the main team workplace is no longer where you sit. The main team workplace is now the cloud environment. If you have two different teams, you want to focus on creating a shared third office, based in the cloud. Build a culture with no siloed conversations. Make sure you invest in face-to-face trips. Even though we’ve worked well remotely, in-person collaboration will always be more effective. It doesn’t need to be 100% but it’s important to have that personal connection between team members.
Lukas: First, figure out your tooling quickly. If you don’t, you’ll end up in a rabbit hole of choice. Second, make your communication and decision making channels explicit. It’s much harder if people have different expectations. Finally, be really mindful of each other's time. When you’re co-located, you can tap people on the back, check to see when someone will return from a meeting. If you’re in a distributed setting and you have meetings, make sure people attend to respect other's time.
Pat: You’ve shared some very useful insights into distributed development that I’m sure others will benefit from. Thank you very much.
Interested in joining us in building the bank the world loves to use?
If you’d like to join us on the journey of building the mobile bank the world loves to use, have a look at our open roles we’re looking for here.
