Introduction

In 2018, the first teams within Rabobank began working in an agile way, organized into tribes and chapters. Today, more than 10,000 employees work agile and collaborate in multidisciplinary teams. Each team is made up of employees with unique skills. Everyone has their own role, and as a team you share responsibility for the final product. Teams have a high degree of autonomy and are allowed to make decisions independently.

1. The rules of engagement of Simplify @ Scale

• Shared vision and roadmap: all teams work together toward a common goal.

• Customer-centric: the customer is at the heart of everything. Teams therefore test their products and make improvements based on the results.

• Ownership: teams take ownership and are empowered to make their own decisions.

• Performance and learning: making mistakes is allowed! We see this as an opportunity to learn, creating an environment where everyone feels safe and encouraged to speak up.

• Collaboration: we share experiences and help each other achieve our shared goal.

• Fact-based decision-making: teams make decisions based on facts, supported by clear objectives and KPIs, customer insights, and validating outcomes.

• One agile way of working: thanks to Simplify@Scale, teams collaborate using a single methodology in a transparent way.

"Thanks to Simplify@Scale, teams collaborate using a single methodology in a transparant way."

2. The challenge

To implement Simplify@Scale within Rabobank, a project team was established to guide the transformation within Business Lending. Two Morphiq employees joined the team to help set up the right processes and determine the best approach for this transformation. When we began the project, there were no useful examples from other tribes to collaborate with, so we had to figure out how to work at scale with more than 700 people in Azure DevOps.

3. Unlocking innovation through tech exploration

Azure DevOps was chosen as the strategic CI/CD tool, offering not only continuous integration and delivery capabilities but also project management features. Previously, we worked with the Atlassian toolset, so we needed to familiarize ourselves with this new platform and the philosophy behind it. To truly understand the tool, we wanted insight into its product vision. How it was designed and how it is intended to be used, according to its creators and product leads.

We began by listening and learning about the recommended usage of the tool. However, as with any technology, even the best-designed solution can fail to deliver value if implemented incorrectly. This is not a reflection of the tool’s quality, but rather of poor implementation. Avoiding this pitfall was a top priority for us.

To ensure we could apply this knowledge throughout the process, and later share best practices with other teams, we aimed to implement Azure DevOps in a way that would be scalable, not just for our teams but across the entire organization, including Rabobank.

The best way to truly get familiar with the tool, despite all the guidance and insights we received from its creator, was to roll up our sleeves and work with it hands-on. This allowed us to gain a real, intuitive feel for how it operates.

4. Technology and processes are enablers, not drivers.

Once we had established a solid foundation for implementing and scaling the solution across a large audience, we developed a plan for how the project would be executed. However, the most critical element of any transformatio, regardless of its size, is the human mindset. Even with the best tools and implementation methods, success is impossible if the culture, mindset, or behaviors are not open to change.

To initiate this transition, we focused heavily on storytelling, starting with fundamental questions such as: Why should we change? What problem are we solving? What’s in it for me? In true Simon Sinek fashion, we made a conscious effort to start with the “why” throughout this transformational approach.

We began by forming a group of business and IT colleagues who would later become the implementation team, ensuring alignment with the various stakeholders involved. From there, we mapped stakeholder relationships, defined the implementation strategy, and set timelines.

Ultimately, the majority of our time was spent explaining the “why” and the “what’s in it for you” narrative. But we didn’t just tell a story, we actively listened to feedback from our audience and emphasized that their voices were essential to our success. In fact, we received a significant amount of input and acted on it, continuously adjusting our course and incorporating smart suggestions, including ideas we hadn’t considered before.

5. Turning Strategy into Impact: The Power of Implementation

After implementing the “One Project” strategy, we quickly started receiving questions from other tribes about how we achieved such success and made this transformation work. The news spread fast and that’s the best kind of story: one that sells itself without you having to push it.

Of course, as a product owner, technology lead, or simply someone involved, it’s important to share what you’ve done, not only to showcase success but also to educate others on what it could mean for them. I believe what made this implementation so successful was our ability to create a scalable strategy and a reusable framework that could serve the entire organization. During the project we have delivered how to set-up the iteration path structures, the delivery plans and how to work at scale with over 50 devops squads, including dependency management. How to apply the right security profiles in pipeline and asset usage and how to configure this at scale, with the right policies in place.

Another key factor was involving the people who would actually use the product, listening to their ideas and incorporating them along the way. This collaboration added tremendous value. The third ingredient was doing the transformation together, as one team, with a large workgroup from both business and IT. And finally, the fourth ingredient was simple: just start exploring.