How a Team Communicates across National Borders
Marta, you have been on board at Unic since 2013 and, as a software developer, you have already realised numerous projects. How would you describe your work for Unic and its customers, from your base in Poland?
As we cannot discuss our ideas and problems face to face, the most important thing in our work from Poland is effective communication. The whole team in both countries, Poland and Switzerland, needs to be on the same page, so we have a lot of video calls, we chat extensively and, most of all, we need a responsive mindset. That means: “Do not ignore anything” – even if you have no time to chat, always inform the other person, don’t just stay quiet.
When joining a project, it is very helpful to have a well-prepared kickoff meeting, where we can get to know the project rules, goals and development processes. This really helps make sure that all team members on the project, no matter where they work, follow the same guidelines.
Most of the time, working remotely goes quite smoothly. After all, we are an IT company and we should be used to digital communication and technical tools (laughs).
Mutual Understanding and Outstanding Collaboration
How did the collaboration on the airport project go in comparison with projects you’ve worked on before?
We always communicate well on our projects, but on the airport project in particular, we achieved a new, unprecedented level of communication. Over the last few years, I’ve never experienced better mutual understanding or more outstanding collaboration between team members than on this project.
For example, we communicated extensively via Teams channels. We did this by using public channels visible to everyone including the customer, and by trying to avoid private conversations. This led not only to transparent and open communication within the team and with the customer, but also resulted in a well-informed team of developers that had a good knowledge of all the questions asked and answered, all the bigger doubts, all decisions made and much more.
Valuable Exchange in the Big Round
How did the team work together? How did you communicate apart from the Teams chat?
We held daily meetings with the whole team. And by the ‘whole team’ I mean back-end developers, front-end developers and testers from Poland and Switzerland. First, everyone gave a quick update on the status of their work. Then, there was a round of announcements and questions for everyone. In the beginning, I doubted that open questions would work in such a large group of people with varying specialisations. I could not imagine that questions from the front-end side would be interesting for back-end developers and the other way round. But I was proven wrong. This round was very valuable indeed. Everyone was able to profit from the information provided there, which resulted in a knowledgeable team that was well aware of any issues.
Furthermore, with Christian Hahnloser and Oriol Torrent taking care of requirements management, we would always get an excellent view of functionalities, from the perspective of both technical AND business needs. They would always find answers to our questions and doubts regarding requirements.
The team members saw each other in person, too. Overall, we had three project meetings with all of us together. And if it weren’t for the coronavirus pandemic, we would have seen each other even more. We met once in Zurich and twice in Wroclaw. In my opinion, these project days are not mandatory for a project’s success, but I found them really valuable. It was so enriching to have the whole team in one room, to actually talk and brainstorm together. And when you know the people personally, the collaboration automatically goes more smoothly.
All in all, we had a great atmosphere in the team – we laughed a lot! This helped us to ease a lot of tension, especially as we had huge time pressure on our deliverables.
Much Laughter instead of Misunderstandings
What was your role on the project?
I was a back-end developer implementing features from the back-end side – processing and exposing required data through the API and preparing Sitecore content structure, to provide the right experience to content authors. As a senior developer, I also assisted less experienced developers if needed. I would answer their questions, help with problems and be available for brainstorming.
Did you experience any cultural differences? And did these cause any misunderstandings?
Not really – I cannot say that I experienced any cultural differences. There might have been some differences in working style in the beginning, which could lead to misunderstandings. But once we had set up our Teams channels and our daily meetings, and once there was clarity on the responsive mindset needed, both work and communication ran smoothly.
On any project, misunderstandings of a technical nature about different aspects of the specification can arise, that’s for sure. But this is nothing that can’t be solved by us talking to each other (smiles).
That is why on this project, front-end and back-end developers worked together very, very closely for all the features we implemented. We discussed in great detail what should be handled on the back-end and what on the front-end side. This helped immensely in avoiding any technical misconceptions.
Of Butterflies, High-Quality Code and Superior Architecture
What technical challenges did you encounter?
Where shall I start? (laughs) It was a pretty challenging project. Everything was new to us: to back-end developers the headless architecture with Sitecore JSS, the Azure stack, including build system – which was also quite new to our operations team, for front-end it was new to work with the headless approach on Sitecore, and working with React was also new to some front-end developers. So everyone had to learn and we had to learn fast!
- It was also the first time we worked with node.js proxy and we had some trouble establishing the ownership of this part of the solution. In the end, both front-end and back-end developers created some changes there.
- For us back-end developers, the Sitecore JSS approach was new. We had to learn the differences between standard Sitecore with MVC and Sitecore JSS. This made testing more time-consuming too, as we had to ensure proper functioning of each feature in both modes.
- We also faced the kinds of challenges we face on almost every project, through using libraries and plugins we haven’t used before. But this is what makes our work interesting – always having to learn something new.
- Another challenge was preparing a completely new build system in Azure DevOps, but this isn’t something I was personally involved in.
Nevertheless, despite all these challenges, what helped us a lot was that the architecture of the platform is exceptionally good! The whole solution is very well thought through. It incorporates Helix principles and Sitecore JSS fundamentals, allowing us to make our code clear, our work efficient and the transition to a headless approach as easy as possible.
What was particularly memorable from a technical, client and team perspective?
One great thing about the headless approach is that the back-end does not have to wait for the front-end! No one was blocking anyone else. In the beginning, we defined a contract describing what data needs to be passed from back-end to front-end, and then we were able to develop the same functionality in parallel. Only the final testing of the integration required both back-end and front-end parts to be completed. Read more about Contract Driven Development.
Furthermore, the code is of exceptionally high quality. We always try to produce good code, of course, but in this project we managed to do all the code reviews very thoroughly right until the end, despite the tight deadlines. Until the go-live for the project, we worked to be better and better and we always found the time to code with care and diligence.
As I said before, we used Teams extensively in this project. The customer also had access to our Teams channels, so we cultivated pretty open communication. Normally ‘only’ the requirements engineers have regular contact with our customers. That was the case here as well, but the customer also had the opportunity to contact the whole team directly, discuss things with us and ask questions. We had a very open, uncomplicated communication style. That was a very pleasant way to work.
From a team perspective I can only repeat that the atmosphere was outstanding. We had a very informal, yet very respectful way of communicating. It was a lot of fun working in this team of great people.
And lastly, can you tell us a story from the project? Something that happened behind the scenes?
Well, I mentioned we had a lot of laughs during our meetings. We would also put a lot of GIFs into code reviews. Going through those pull requests is really good if you need to cheer yourself up.
The code word for the project was ‘Butterfly’ – we were building a butterfly that would provide an exquisite user experience. So butterfly was often used in punchlines. It also inspired us to use a whole collection of GIFs from the film, A bug’s life, to represent different situation of the project. In particular, when a particular functionality was close to being completed and a sprint end was approaching, we would use this specific GIF.
With technologically highly innovative solutions and a clear UX orientation, the new multisite platform covers the entire system landscape of Zurich Airport and thus meets the diverse needs.
Two time zones, three countries, three native languages, none of which is English. In the interview, our test manager Romy Maurer-Wysseier talks about the experiences of working together in an international testing team to prepare for the relaunch of the Zurich Airport platform.