Key Takeaways
- Using a collaboration model and group practices based on Conway’s Law helped to optimize for faster customer value delivery across the whole multi-site team setup for a banking solution, and to avoid development of multiple local solutions.
- Common goals that were aligned and understood early on ensured value delivery across different markets; these goals supported decisions about adaptations to the architecture and to address potential risks and dependencies between countries.
- Continuously evolving communication structures, IT system architecture, and organizational design, enabled delivering unified digital solutions that are scalable across different markets.
- A shared understanding of agility, engineering practices, and the concept of a group solution was supported through continuous education, active involvement of agile coaches with both teams and leadership, and the co-creation of group collaboration agreements.
- Group roadmapping and group retrospectives fostered a one-team mindset and supported effective multi-site collaboration by improving agile practices across countries.
In this article, we will share our practical experiences and provide concrete examples from our work with multi-site teams that built a single solution and delivered value to customers across various European markets. Our banking group, headquartered in Vienna, operates in eleven Central and Eastern European (CEE) markets and serves approximately eighteen million customers. We are bringing real-life stories and lessons learned from developing two banking products, Lending and Foreign Exchange (FX), and their evolving architecture over time.
Vision
In the lending area, customer needs and expectations differed significantly from those assumed by the bank. To apply for and obtain loans, customers had to visit bank offices two to three times, and had to fill out approximately seven hundred fields in a substantial amount of documentation that needed to be physically submitted. We were losing money in this business, our internal processes were almost entirely manual, backed by approximately thirteen legacy systems.
In our Foreign Exchange product, we faced the potential loss of customers due to the digital competitors (such as Revolut, N26,..). There was no online access to real currency rates, and 2-3 different channels were used per country. We knew that resolving these issues for FX and lending would give our banking group a competitive advantage.
We started with a hypothesis: We can build a single digital solution that is simple to use, secure, and scalable, improving customer experience by reducing time to money, and increasing gross income across all our markets.
The expectation was also that a single solution for the entire banking group would help streamline business processes and IT architecture. It would help deal with diverse legacy back-end systems and enable unified, real-time integrations.
Ultimately, digital solutions would bring a competitive advantage to the Lending and Foreign Exchange businesses across all countries where we operate as a banking group.
Challenges With Multi-Site Team Setups and How We Addressed Them
To validate our idea, business leaders from our headquarters in Vienna and the Croatian subsidiary agreed to launch our Lending MVP for small and medium companies in the Croatian market. We formed a cross-functional team with representatives from both organizations, bringing together the skills required to develop and deliver a lending product end-to-end. The team was highly international. Assembled entirely remotely during the corona lockdown, it included members from six different cultures.
One of the first key decisions made was whether to develop a fully in-house, greenfield solution or purchase an off-the-shelf product. We identified a suitable external solution that could serve as the foundation for a future group-wide solution and decided to engage a third-party vendor from Serbia.
Figure 1: MVP Croatia
Onboarding the Vendor to a Cross-collaborative Way of Working
The main challenge with the vendor was that they didn’t really understand our expectations in terms of a cross-collaborative way of working and were pushing for a well-known approach: “Send us your functional specification and we will deliver it for integration and testing”. This was a no-go for us!
After many discussions, negotiations, and also investing in educating the vendor by our agile coaches, an agreement was finally reached: Vendor representatives would join the team, and we would all work as one Scrum team.
Embracing a one-team mindset, regardless of where we sit, where we come from, or for which company we work for, was the principle that helped us overcome the challenges mentioned above. The importance of embracing a one-team mindset was proven with every new team onboarded in the product group.
Scaling Across Markets
Based on learnings from the first market in Croatia, business leaders recognized the significant potential to scale the digitalization of lending business for small and medium companies across the markets of the entire Raiffeisen Bank International group. There was a strong desire to involve subsidiaries from other countries, such as Romania, Bosnia and Herzegovina, Albania, Kosovo, Czechia, Hungary, and Serbia, as soon as possible.
We, agile coaches, used an approach to set up one country team after another, with several months of time lapse, and in a short period of time, we found ourselves with six teams in different locations across Europe, working jointly on one digital solution. Currently, there are eight teams, comprising approximately ninety people, working within this one product group.
Figure 2: Multi-Site Team Setup
Dealing With Local Specifics
Expanding into every new market brought the challenges of local specifics in terms of different customer needs and expectations. For example, clients in some markets, where the assumption of a fully digital experience was proven, don’t want to go to the bank office at all while in others they still prefer to have human touchpoints. Based on findings like these, we continually refined our approach and evolved our solution design. In the lending solution, the 80-20 principle is followed. That means that approximately up to twenty percent of local customizations are possible.
Navigating Regulatory Complexity
Banking is a strictly regulated environment in itself, and with new markets, we also encountered different, locally specific financial regulations. For instance, we had to deal with different credit risk ratings in different countries, as some countries are part of the EU and others are not. Additionally, modernizing infrastructure and moving lending systems to cloud was considered materially significant externalization by country national banks, whose approval was required.
Designing a Collaboration Model and Group Practices
Conway’s Law was a great reminder that our existing communication pathways shaped by established country legal entities and existing IT systems would likely lead to the development of multiple local solutions serving the same purpose with different architectures rather than one unified group solution. Recognizing this multiple solution need, we designed the group practices to adapt our communication structures to optimize for fast delivery of customer value for the whole product group.
Group Collaboration Agreements
Firstly, we agreed to speak a common language, using English in documentation and communication, guaranteeing the basic understanding across countries. Secondly, time has been invested in aligning countries on their agile maturity and common understanding of what “cross-functional teams” mean, actively coaching teams and leadership in country banks.
Both points are simple ideas, but are difficult to implement because our plans involved creating new habits and stepping out of the comfort zones for already established organizations.
Each new onboarded country had a different level of understanding of good engineering practices, specifically in terms of how we continuously integrate and deliver software. Having all teams follow predefined Raiffeisen Bank International engineering values and principles (e.g., automated CI/CD pipelines, testing strategy, etc.) helped us overcome this challenge. We achieved these onboarding successes through group collaboration agreements.
Group Roadmap
We made sure we only followed one group product strategy roadmap across all countries, keeping it flexible through continuous realignment. When we started building the product for the first country, it was logical that we would have only one product roadmap and backlog. As other countries joined, the first thing we did was to sit down with all of the teams and ensure that we had a common understanding of our group product goals. From there, we jointly derived and constantly adapted our group’s product roadmap. Group roadmapping sessions included representatives from each country and were held every four to six weeks. During these sessions we reflected on group strategy, group roadmap updates, aligned on architecture, and risk discussions.
Our experience showed us that if we can ensure our goals are aligned and everyone understands them, half of the job is done. During this session, local country requirements are discussed and prioritized considering our group product vision, goals and the fact that we are striving to build one group solution.
Evolving Architecture as a Group
Figure 3: Group Architecture
In order to design a group solution, we also had to address the topic of legacy in our solution architecture. Remember, we were digitizing our Lending and Foreign Exchange business, building modern, easy-to-use solutions with supreme customer experience, deployed in the cloud, and integrated with our existing legacy IT systems.
For example, if the customer wants to make a foreign exchange transaction, there is a need to integrate with that country bank’s existing core banking system. Now here comes the stitch – in different countries, we use different core banking systems, and they are usually developed by different vendors. Neglecting this fact would lead us to create local solution architectures, local integration approaches, and locally customized products, which contradicts our goal of a one-group solution. Without continuous conversations about architecture with all involved country teams, we would not have considered beneficial architecture alternatives.
Our first experience with this issue was when a group architecture approach for single sign-on functionality (allowing customers to login to the FX system directly from an online banking platform) was suggested. The group integration layer based on REST APIs was jointly elaborated with Romanian and Croatian teams, and ultimately decided to be the simple plug-and-play solution for all the countries involved. When the time came to integrate the solution in Hungary, the cost of estimation suddenly increased due to differences in architecture and access to the local identity management system. This cost increase resulted in a temporary customized solution for Hungary and a creation of technical debt that had to be cleaned up later.
Group Retrospective
Major events in our collaboration include regular group retrospectives, attended by representatives from all countries, where we address ways of working, agile maturity or differences in development approaches. I will never forget that one session, just before the major roll-out in our Foreign Exchange product. Raiffeisen Bank Romania openly shared that they were lacking manpower and skills to perform integration testing, and by doing so, informed us that the group release would have to be postponed. Their colleagues from Raiffeisen Bank Croatia wanted to keep the release date, and offered to support the testing and upskilling of new team members. These colleagues understood we were all in this together.
Originally started as a place to reflect on and adapt our collaboration model, group retrospectives have evolved into a space where we cultivate a one-team mindset, fostering trust, transparency, and learning across countries.
Product Ownership
During our expansion into different markets, we designed a setup with a single product backlog and a single person in the role of Product Owner. Soon we faced challenges on who can understand all involved markets’ specifics, who makes priorities between them, and how that person can get easy access to the local markets’ end customers.
Our solution was to employ a local Product Owner in every country team. That person knows local market needs and acts as a local customer representative, so that the local customer regulations are fulfilled and included in the Group Product Roadmap. The Group Product Owner is the overall visionary and makes final decisions regarding priorities across all countries and markets.
How Do We Know That We Are Successful?
Digital transformation of lending for small and medium companies is the absolute game changer in all our markets in the CEE region, as seen in our measurements.
The time-to-money measurement for our customers, previously taking weeks, has been reduced to fourteen minutes on average, allowing customers access to secure financing anytime and anywhere without the need for paperwork. From the bank’s side, revenue in this business segment increased by fifty percent, and our internal processes were significantly streamlined, resulting in full digitalization of lending.
Similarly, the FX area, where the business was at risk of being lost to digital competitors, has been turned around, with trading volumes measured in millions of euros per month. Customer satisfaction is very high and continues to improve.
When we compare our current engineering and efficiency metrics to those from four years ago, the progress is impressive. Back then, production deployments occurred only twice a year. Today, we average twenty-one deployments per quarter, with a current average cycle time of just fourteen days. Incident resolution used to take days or even weeks, often requiring coordination across multiple departments. Now, most incidents are resolved within minutes. This improvement is largely due to the shift in responsibility to the product teams and the adoption of the “we build it, we run it” approach.
Summary and Conclusions
Building multi-site teams across diverse markets has taught us that true collaboration goes far beyond tools and processes. It is about aligning goals, mindsets, and trust. On our path to success, we took many small, intentional steps: aligning business goals, co-creating team agreements, adapting communication structures, evolving our solution design, and continuously learning from one another. Embracing diversity while committing to a one-group solution enabled us to deliver real customer value at scale. The one-team mindset became our cornerstone, turning regulatory hurdles, architectural complexity, and cultural differences into opportunities for innovation and shared ownership. Key group practices such as joint retrospectives and roadmapping created spaces for transparency, feedback, and collective growth.
Today, the impact is measurable in both customer satisfaction and business performance.
Note
This article summarizes our practical experiences and provides concrete examples from our work with multi-site teams that built a single solution and delivered value to customers across different European markets. It was originally delivered as a talk at Agile Meets Architecture 2025.
