Global Patchwork – How to Co-Create a Product in an International Team

Collaboration in an international team can bring numerous challenges, which, with a bit of effort, can easily be transformed into opportunities. Here are some of the key challenges faced by organizations operating in a global patchwork environment:

• Cultural Differences
  Working as a team in an international environment means confronting cultural differences that can affect communication and decision-making processes. Being aware of and respecting these differences is crucial to avoiding conflicts and misunderstandings.
  
• Different Time Zones
  Team members may be spread across various time zones, making it difficult to synchronize meeting schedules and collaborate in real-time. Flexible communication solutions and schedules that accommodate time zone differences are essential.
• Language Barriers
  Language can become an obstacle to smooth communication, especially when team members have different native languages. Ensuring clear communication and providing translation support is vital to prevent misunderstandings.
• Technological Disparities
  Team members might use different tools and technologies, making it challenging to integrate their work and collaborate effectively. Selecting common tools and platforms is key to enabling seamless cooperation.
• Diversity in Skills
  Each team member brings unique skills and experiences, which can lead to challenges in managing varying levels of competencies and expectations. Ensuring equal participation and opportunities for growth is important for all team members.
• Coordination of Activities
  In a global environment where team members may be dispersed across different countries, coordinating activities and tracking project progress can be difficult. Effective project management methods and regular progress reporting are necessary to stay on track.

When the decision was made in 2020 to create a dedicated team to deliver products for institutional clients on the MyRaiffeisen platform, none of us anticipated how challenging it would be to establish cooperation between the already two-year-old teams in Vienna and the newly formed team in Poland—all while maintaining the flexibility and autonomy of the latter. Four years later, it’s safe to say the team is now operating effectively, and institutional clients have received many new products in recent years that they rate highly.

I still remember my first discussions about the Eagle project. At that time, I only had a rough idea that we were to create a new Scrum team with its own Product Owner and all the roles necessary to develop the intended product. However, it was also clear that this would have to be done on a platform built and managed by Vienna’s DaVinci team, while ensuring maximum reuse of components already developed at that time.

Two Product Owners making decisions about a single platform, building functionality on a codebase that already carried significant legacy, and running a project across two countries with a team of 40 people from 14 nationalities—where every third person spoke a different native language—felt like a real challenge. And it truly was.

The road to the current collaboration model was far from smooth, often marked by numerous arguments, disputes, tears, and frustrations. One could probably write an entire article about how we reached the model we use today. However, after these years, we’ve developed a set of principles for collaboration—a hybrid of various scaling frameworks, such as Nexus, Scrum@Scale, and LeSS—that work quite well for us. Here’s what we’ve established.

In the development of the MyRaiffeisen platform, we divide roles into those assigned to specific teams and shared roles. Let’s start with the first group. On the business side, those responsible for delivering value are individuals dedicated to handling different client segments, supported by business analysts. The development teams, backed by Delivery Managers, operate independently and focus on working with specific client groups. On the process side, Scrum Masters oversee the teams, with support from UX designers and testers who perform their designated roles.

To maintain platform consistency, there are also many roles not assigned to specific teams but overseeing the overall product. Among these is the Solution Architect, who ensures technological dependencies within the project are met. DevOps, who have complete knowledge of the platform’s infrastructure, are also available to support each team and coordinate the release process, which is unified for both the Eagle and DaVinci teams.

To ensure knowledge is evenly distributed across all competency groups, each role has its own Chapter, where knowledge is exchanged to ensure the effective development of the platform.

The approach outlined here is certainly not final and continues to evolve. However, after these years, we can confidently say that the current state allows us, with four scrum teams and over 40 people involved in building the platform, to maintain technological consistency where necessary while also preserving flexibility and autonomy when it can bring value. This is also an example that simple solutions, when well-structured, can be entirely sufficient to address dependencies, and that a complex framework, meticulously planned down to every detail, is not always necessary to build an effectively functioning team.

For functionality dedicated to specific products, the situation is relatively simple. The team responsible for creating a given product is also accountable for its integration with the platform and its maintenance in production. Responsibility is end-to-end — from selecting technology (with limitations related to adapting to the current tech stack on the platform) to fixing any errors reported by clients. This approach has allowed the Eagle team to maintain some autonomy in tool selection and freedom in making technological decisions, thereby reducing the need for constant discussions and alignment in every aspect.

The situation is a bit more complex when making changes to components used across multiple products on the platform, where fixes could potentially affect several areas of the application. For this type of functionality, the process looks as follows:

1. Analysis – The team planning to make changes to a shared component conducts a technical analysis of potential fixes, typically planned as a spike in the sprint. This involves reviewing the current code and mapping out dependencies and potential proposed change models.
   
2. Discussion with Developers – Along with the analysis, discussions take place with developers from other teams, usually those with the broadest knowledge of the given component. We are currently implementing the concept of Component Stewards, where specific individuals are assigned to particular components as experts.
3. Discussion with the Solution Architect – Potential solution models are discussed with the architect to obtain approval for a specific approach and to review the associated risks of each solution.
4. Demo of Spikes – From our perspective, this is the most important moment: a regular meeting of all team members from both Eagle and DaVinci. During this session, the results of the discussions and analyses are presented, feedback is gathered, and the final implementation decision is made.
5. Implementation – Development is carried out based on the agreed assumptions, and cross-team code reviews are conducted to ensure knowledge about the implementation details is shared across teams.

At the same time, on the business side, regular coordination meetings are held every two weeks. During these meetings, business analysts and product owners discuss all planned changes to shared components and analyze the risks associated with these plans. At this stage, we also review in which sprint the potential changes will be implemented and whether they conflict with the scheduled work of other teams, or if too many significant changes are being introduced to the platform at once.

This entire model is evaluated and monitored regularly during weekly meetings with Product Owners, Delivery Managers, and Scrum Masters. During these sessions, we exchange feedback from the teams gathered during retrospectives, document potential impediments and ways to address them, and discuss which elements of the process need improvement and to what extent.

The approach outlined here is certainly not final and continues to evolve. However, after these years, we can confidently say that the current state allows us, with four scrum teams and over 40 people involved in building the platform, to maintain technological consistency where necessary while also preserving flexibility and autonomy when it can bring value. This is also an example that simple solutions, when well-structured, can be entirely sufficient to address dependencies, and that a complex framework, meticulously planned down to every detail, is not always necessary to build an effectively functioning team.