This report details a change management journey that led to a significant transformation in the way development teams inspect and adapt their work within an international fintech corporation. Our focus is on the evolution of a specific event, the Sprint Review, and how it culminates in a groundbreaking first: the team collaborating with users to investigate the results of their core product work during the Sprint Review. From in-depth research to mindset shifts, we will discuss the challenges and achievements along the way.
1. INTRODUCTION
In my first week at an international fintech company, I attended a hybrid demo event hosted by one of the teams I was soon to take over as Scrum Master. A developer’s sonorous voice welcomed the internal guests and proceeded to present the stories on the Kanban board, followed by a product demo. To my surprise, the event concluded without any questions or feedback from the attendees. Intrigued, I delved deeper into the company’s practices and discovered that this reporting style was the customary approach for reviewing sprint results, driven by complex underlying reasons.
Fast forward through an arduous eighteen-month journey, and one of my teams experienced a defining moment—an incredibly successful sprint review with our valued users. The room buzzed with energy as meaningful and dynamic discussions unfolded. Users, managers, and team members alike were swept up in a wave of excitement. This transformed environment fostered an inclusive space that brought together a diverse group of attendees, each armed with their unique goals and perspectives. It became a catalyst for change, alignment, and collaboration with our users and stakeholders and evolved into a vibrant hub where ideas flowed freely, and challenges were confronted.
Now, join us as we invite you on an adventure—an exciting journey through the labyrinthine corporate world, teeming with numerous constituents yearning for transformation.
2. Background
SimCorp is a global organization with over 2,300 employees representing more than 60 nationalities spread across the world. Nearly 50% of the world’s top 100 investment managers utilize SimCorp’s integrated investment management solutions. Despite being over 50 years old, SimCorp has undergone several iterations of Agile. About a year after I joined the company, it announced the end of its Agile Transformation (based on SAFe). Shortly after we had our first real users at the Sprint Reviews, another iteration of the company’s restructuring began.
SimCorp’s development team is extensive, and its product is complex. At that time, it consisted of around 600 people and formed Agile Release Trains (ARTs), each with a defined area of responsibility. As with any large company, each Train had its peculiarities: some enjoyed more freedom regarding technology, while others faced constraints due to the complexity of the architecture. While some teams worked on the core and tended to serve other teams with a part of the functionality, there were also Scrum teams delivering classic end-to-end user stories.
3. Story
This narrative chronicles my journey of driving change as a newly hired Senior Scrum Master: from the initial investigative steps to the successful iteration with my teams, where we inspected and adapted our work results alongside real users. The story is structured hierarchically, detailing the evolution of the initiative and the lessons we learned at each stage.
Before joining SimCorp, I had over eight years of leadership experience at small companies and startups, where I functioned as a Swiss Army Knife, taking on a wide range of responsibilities. I made decisions regarding processes, scaling approaches, hiring strategies and often engaged heavily in sales and marketing work. However, at a large company like SimCorp, my area of direct influence was narrower, requiring me to adapt, navigate the complex environment, find allies, and communicate my ideas carefully. In this new context, my previous experience helped me to undertake bold changes, despite skepticism and apprehension regarding my initiatives. I persisted, drawing inspiration from the small victories of my teams and colleagues across departments and strategically planning each step.
I share this story in the hope of inspiring other change agents to dream bigger. By presenting my experience in this format, I aim to provide confidence in how change management tools and approaches can work in complex environments. You’ll learn what required more attention and which factors increased the chances of our change’s success. If you find this information useful, can apply it to your work environment, or have insights to add, I’d be delighted to hear from you.
3.1 Investigation and goal setting
After my first month of onboarding, I compiled a long list of potential initiatives to improve the work environment and maximize business value. To determine which ones to pursue, I conducted extensive research to gain a comprehensive understanding of the large organization. Adhering to the customer interview guidelines to ensure unbiased insights (Torres), I engaged in extensive conversations and made many observations. Identifying the individuals who shared my enthusiasm for implementing specific initiatives presented another challenge. As I worked on these initiatives, I ensured that the chosen changes would benefit both our company and the users without conflicting with the company’s goals or disrupting the operations of other departments. I was inspired by the change management stories of others and benefited from their experiences (Heath C., Heath D.).
Following my observation of one team’s demo meeting, I attended other teams’ demos, spoke with fellow Scrum Masters and my development manager, and had an in-depth conversation with every team member to understand their perspective. Through this process, I discovered that:
- The “reporting” style of the meeting was a pattern inherited from the waterfall days. Teams did not need to refine their presentation skills to collaborate with external stakeholders, as they only dealt with those possessing technical knowledge.
- Fear of failure and judgment hindered open and safe discussions, preventing an effective feedback loop. Some teams had negative experiences after reporting challenges or problems.
- The specifics of the product, along with its sales and marketing approach, added complexity. SimCorp’s business model relied on enterprise sales, often targeting conservative, top-down organizations. This meant limited opportunities for early interaction with users. Furthermore, even for those with user-facing responsibilities, engaging users outside of routine events proved challenging.
- The complex product architecture required multiple teams to deliver an end-to-end feature. Showcasing part of a feature made little sense, necessitating cross-team communication and alignment to demonstrate a complete user journey.
- The implementation of the product at the customer working environment was a complex process that was handled by a special department and dedicated specialists.
After this investigation, I realized that I still lacked sufficient knowledge to plan the change. It felt like the tip of the iceberg: I was unsure how to reach end users since a separate team handled product implementation. Another gap involved collaborating with sales and the newly created customer success department. Moreover, even if I managed to organize a meeting with invited users, making the meeting valuable for both the team and users seemed impossible under the current setup. At first glance, this initiative may have appeared less perspective compared to other items on my agenda. However, I believed it had the potential to create a substantial impact in various areas—enhancing team morale and motivation by increasing their sense of purpose, improving the feedback loop, and reducing unnecessary waste. I recognized the need to proceed cautiously, as rushing implementation could lead to resistance from the teams.
3.2 Sprint review and Agile mindset
Having gained a high-level understanding of my client and organization, I set out to define the smallest possible step that would be comfortable for my colleagues while also stretching their capabilities. I was fortunate that the core of my first development team was ambitious and interested in self-improvement. They were also very straightforward and critical, ensuring my newcomer enthusiasm and startup experience did not lead to unnecessary risks.
My first step involved educating the team about sprint reviews and sharing my experiences. In addition to explaining the role of sprint reviews in creating a feedback loop and obtaining early feedback, I provided examples of how different companies handle them in various contexts. I also candidly shared my past experiences, including both failures and successes (Uit de Weerd, Fridjhon). After the training, we brainstormed about what we could accomplish as a team and the support we needed from others. This marked our first significant shift away from the “reporting” mindset.
During our discussions, the team acknowledged the lack of connection with end users and customers, expressing difficulty in understanding their contribution to SimCorp’s business value. This real pain of my team became a motivation, a critical focus for future work. They also voiced concerns about including new individuals in the demo, fearing that demonstrating only part of the functionality would be overwhelming. I suggested we begin by working on their presentation skills, and the idea was well received.
From that point on, we decided that all meeting preparations would involve:
- Conducting feedback sessions after each presentation, both internally and externally, including interviews and surveys with invitees, other teams, and leadership groups;
- Teaching relevant public speaking materials in small increments for practice combined with individual coaching;
- Rotating presenters to allow more team members to practice actively;
- Agreeing on a general presentation concept and set of questions. We worked out a presentation template that already implied a more interactive approach: agenda page, specific questions for the participants (specific questions stimulated the invitees to answer, while the general questions like “how did it go for you” were usually met with silence), feedback on the work, next steps and challenges, etc. With each review meeting, we iterated on the format and trained to generate questions. This allowed us to spend less time preparing and to be confident in what we were practicing;
- Brainstorming about who to invite to each meeting, focusing on individuals directly involved in or dependent on the functionality.
What didn’t work at that stage included:
- Inviting non-technical people as colleagues who could help invite them expressed concerns and argued that higher-priority work would prevent their attendance;
- Suggesting purely interactive approaches, such as having invitees navigate new functionality themselves (Pieskova);
- Overcoming the fear of failure versus embracing the fail-fast mindset. Although we made significant progress, we still had to find ways to work with individuals holding opposing beliefs.
These proposals were too far away from the current context, and new people and a completely different format were already enough of a stress factor for the team. However, I was proud that I had initiated a major mindset change, transforming a demo meeting with a reporting function into a true sprint review focused on improvement and iteration. This approach made the team more receptive to criticism and more open to sharing challenges. As they discovered that sharing difficulties led to assistance rather than unconstructive criticism, iterating became easier.
It’s worth noting that I still had to address and stop toxic comments and remind people of the purpose of the meeting. I encouraged the sharing of challenges by highlighting the potential time saved and mistakes avoided, making this transparent for all meeting attendees. My focus was also on the overall creation of a positive and safe atmosphere (Pieskova). While such situations are normal, I believe it’s important to facilitate them attentively, ensuring negative behavior remains the exception rather than the norm.
3.3 Non-technical stakeholders at the review
A few months after working with my first Scrum team, it was time to take on the second. It was one of the most mature teams in the company, with heavy computational and financial challenges and critical end-to-end functionality. Such specifics of teamwork and responsibility for end-to-end functionality opened many more doors for experimentation.
I started with individual talks and then moved to team education and brainstorming just like with the first team. Training on the purpose of the sprint review and an inspect-and-adapt mindset, along with the shared experience of my first team, generated a lot of interest but no concrete ideas at first. The first team’s practices were found interesting, but they were off the beaten track.
As we became more familiar with each other, we began to iterate on our meetings. The team’s Product Owner seemed to be a classic “innovator” type of person. Not only does he like to experiment with new ideas, but he also builds extensively on them. The first iteration already implied quite significant changes:
- We have added the routine of discussing the Review plan beforehand with the whole team and iterating on this format and approach.
- The Product Owner created a Miro board for all Reviews and added a roadmap there as an opener after trying out a presentation template. This added more context and often sparked a lot of discussion.
- We invited several consultants working directly with the users to the meeting. The Product Owner already had strong relationships with them. He was able to invite the most receptive and easy-going ones on the first try. Treating them as the target audience led to their satisfaction with the meetings, and they rated the return on time spent as very high. This success encouraged us to think boldly about future endeavors.
When I think about what didn’t work, it’s hard to recall any significant attempts. At the time, I was sure that it was not good for the team to have only testers presenting, especially after the success of the previous team where every team member had managed to demo. But it felt flat, and I soon gave up on the idea, as it was not about improving the presentation skills of this team, but rather about successfully distributing roles. Later on, we did have some developers present, but this was driven organically by functionality, not the need for practice.
3.4 Sprint reviews by functionality, not team
In one of our sprint review brainstorming sessions with my first team, we concluded that demoing a piece of functionality exclusively was a big showstopper for our next iteration. The feedback on it was not making a big difference, and even asking for it felt flat. So we decided to try reviews by feature rather than by team. As this required a lot of adjustments from other teams, the idea wasn’t picked up actively from the beginning. But once I spoke with everyone, scheduled the session, worked out an agenda with all the teams, and agreed on it with the stakeholders, the result was unprecedented. Finally, we joined other teams who were completing the user journey and planned joint reviews.
Coordinating the Review agenda was challenging and time-consuming, but we never regretted this decision:
- It was easier to invite stakeholders because they didn’t have to prepare for several different meetings but just one. Additionally, we covered a lot of ground in the meeting itself, rather than coordinating later in writing.
- We also managed to invite user-facing team members – consultants, and it soon became a habit. It is easier to propose after you have successful cases in the company – people follow “early adopters”.
- We aligned the agenda with stakeholders, and at the beginning, I texted each one directly about their interest in the topic and adjusted the agenda accordingly.
- Cross-pollination between the teams on how to conduct a successful Sprint Review meeting became much more active than before. It is worth mentioning that, as with every change, we also encountered skepticism and hesitation to collaborate. The teams had to allocate much more effort to preparations than before.
3.5 Finally, reviewing sprint results with users
After establishing group sprint reviews, setting the agenda, and iterating the approach for each of our meetings, it became routine for my teams. Although we practiced small improvements almost every time, significant changes were rare. However, I didn’t get tired of asking who we could invite as stakeholders and what facilitation experiments we could do. Then, to my surprise, I received an unexpected answer.
The consultants and the product owner of the second team shared that they wanted to invite representatives from one of our important customers to the review. These guests had worked extensively with our product and, according to the consultants, were among the “innovators” or “early adopters” in their organization. They were open-minded and pleasant to work with, and it felt safe to experiment with them.
Our preparations were extensive. We completely revised our format, asked clients about the use cases they wanted to see, and ensured we prepared a relevant demo that we could discuss in detail. We also prepared numerous questions to have at hand, ranging from general to specific questions about their use of the product, the next user flow they would try after the feature delivery, and their concerns.
To our surprise, our first attempt was a success. The demo was followed by many questions, and both users and consultants shared satisfaction and enthusiasm. When I congratulated the team, they shrugged it off as nothing special. I understood their perspective because their work naturally and gradually led to this success.
Other Scrum Masters and Product Owners were interested in adopting the approach, and the executive team supported the initiative. The path we took helped SimCorp go through a product area transformation where all departments were supposed to work closely together on specific product areas, which naturally mirrored the setup of joint sprint reviews by functionality.
However, not everything went as planned, and we had to learn quickly. A waterfall of feedback, both related and unrelated to the product, began at the first Sprint Review with users. Most of the general feedback could not be handled solely by our team efforts, and it was uncomfortable to point it out repeatedly. It was difficult to set expectations, as every word in the meeting went directly to the client. When we once mentioned a plan that we couldn’t implement, we decided to collect questions about the plans but address them later to allow enough time for consideration. The team was unhappy with the amount of time it took to prepare for such a meeting and then work through the feedback. However, all these challenges led to solutions we could work on, and we did work on them.
In particular, to address the waterfall of feedback, we later invited users to the Quarterly Event of our Agile Release Train. At that time, our Quarterly Events primarily aimed at socializing and fostering creative initiatives to strengthen networking ties and promote cross-pollination of various initiatives. It was an excellent opportunity to have more manpower to address user challenges. Since I was leading the change, my team of Scrum Masters encouraged me to lead the interview with the users. About 120 members of the development team and people from other departments, including the leadership, attended the event. As it was the first interview, it was easy to prepare questions based on what users shared in the reviews: how they saw collaboration with our company, their biggest pain points, and what they found most useful in the product. Meeting our users not only helped us learn from the extensive feedback but also allowed us to meet them, trigger networking, build empathy, and create personas.
3.6 Results
Let’s examine the direct and indirect results of our initiative:
- Regular Sprint Reviews with non-technical stakeholders and even users, leading to a shorter feedback loop;
- Collaboration with users and consultants to improve the product team’s strategic decision-making;
- Sprint Reviews by functionality rather than by teams, which served as good preparation and a ready process for the next level of organizational restructuring;
- A workflow template to follow when implementing changes to Sprint Reviews in the organization, used by Scrum Masters and Product Owners;
- Interest in the topic throughout the organization, leading to knowledge sharing and initiatives driven by other Product Owners and Scrum Masters across the company;
- Increased empathy for customers and a further incentive to create personas and use them in daily work;
- Local improvements in the teams, such as enhanced presentation skills, increased confidence in their team’s contribution to the business value of the company, and stronger networking connections with other departments, leading to more initiatives.
There were also numerous results that are difficult to measure and illustrate with concrete facts, but I believe they ultimately reinforced a great mindset change. Teams embraced the “fail fast” mindset, many team members gained more confidence and initiative than before, and continuous improvement iteration and challenging the status quo became the norm.
Despite initial skepticism, I prioritized the sprint review initiative and unintentionally contributed to the foundation for future value stream transformations. When I left the company, I was proud of the progress we had made, including successful support with remote work and the kick-off of DevOps initiatives. However, I consider the lasting impact of the sprint review initiative one of my most significant achievements. The teams had started to work more closely with other departments to deliver a seamless end-to-end user journey.
4. What We Learned
At first glance, the most significant learning from this initiative may seem like getting customers to participate in sprint reviews. However, in my opinion, the most important lessons were understanding how to implement systemic change in a complex environment and the side effects of doing so. Here are some key learnings:
- Working with a mindset is always time-consuming but extremely rewarding. Training, educating, and coaching the team has yielded the most results. While not all teams may have hosted clients at reviews, the shorter and more productive feedback loops, effective inspect and adapt routines, new skills gained, and new relationships with internal and external people contributed to significant progress.
- “Nothing will stop the idea whose time has come” is a saying that can describe changes in both societies and organizations. A certain level of maturity and desire within the team is necessary for change to happen. However, the right environment and training can lay the foundation for such change. In our situation, despite initial feelings that change was impossible, progress was made.
- Naysayers often have a louder voice in large organizations than in small, young ones. But if your work produces results that are hard to argue with, their voices will fade. It is also important to investigate and recognize the difference between naysayers and those whose warnings should be heeded. The Product Discovery tools and principles can help to structure this investigation and prevent cognitive bias of change agents.
- Choosing the next smallest step that is both challenging and comparatively comfortable is the art of moving forward at a pace that makes a change stick. In large organizations, it is crucial to dedicate enough time and investigate opportunities and risks together with team members before taking that step.
5. Acknowledgements
I am immensely grateful for the incredible SimCorp team that made this story possible. I would like to express my heartfelt appreciation to my dedicated teams at the time, Dark Side and P-Team, for their unwavering commitment and open-mindedness. I extend my sincere gratitude to our exceptional Product Owner, Oleksandr Sharapov, whose remarkable leadership and vision played a pivotal role in our success. I would like to acknowledge the crucial contributions of the consultants Maximilian Stahler and Alexander Schnitzler. Although I am unable to mention the pioneer client names due to the constraints of nondisclosure agreements, their partnership and insights were integral to our achievements. Last but not least, I want to thank Siva Kumar for shepherding my report.
REFERENCES
Heath C., Heath D. “Switch: How to Change Things When Change Is Hard”, 2010
Uit de Weerd, Fridjhon “Systems Inspired Leadership: How to Tap Collective Wisdom to Navigate Change, Enhance Agility, and Foster Collaboration”, 2021
Pieskova Y. “How to cook up the positive atmosphere for your team,” https://www.yuliia.co/post/how-to-cook-up-positive-atmosphere-for-your-team
Pieskova Y. “Sprint Reviews at Scale and Remotely,” https://www.yuliia.co/post/sprint-reviews-at-scale-and-remotely
Torres T. “Customer Interviews: How to Recruit, What to Ask, and How to Synthesize What You Learn,” https://www.producttalk.org/2022/12/customer-interviews/
