Large Dutch Bank |Our Journey Towards Agility at Scale
Cesario Ramos, Mr. X, Ms. Y and Mr. Z.
BECAUSE OF LEGAL REASONS I CANNOT USE THE REAL NAME OF THE COMPANY AND PEOPLE INVOLVED
This article is about how we improved on the Dutch Bank Spotify inspired model in a tribe.
We work with over 20 teams on our Business Lending product.
We develop our product across 3 sites, with dispersed teams. Each team contains business, IT and operations skills. In this configuration we deliver valuable product for our customers every 2 weeks. We did this by amongst others, adopting LeSS principles to further optimise our Spotify inspired way of working.
So, how did we transform?
In this writing we share our story from 4 different perspectives.
The perspective from:
- The director of the tribe.
- The consultant.
- The head of IT.
- The Product Owner of the Product Area related to all customer journeys
Observations: Why did we do this?
Around 1,5 years ago I ( director here ) came to lead the tribe; a 500+ people group where business and IT people work together in squads to create the business lending product, and where the related customer loyalty teams are within our scope. Previously, I was involved in setting up a retail bank from scratch and in the development of mortgages solutions. During my previous job I worked intensively in tuning the agile way of working into a model for the performance organisation.
In the first few weeks I decided to spend my time observing the group.
In my observations I noticed that the teams were having fun and seemed to work in line with the purpose of their squads. The teams were autonomous and organized themselves using lots of sticky notes and standup meetings.
All seemed okay, but this was about to change as we approached our first big product release.
We delivered product in 6 month releases. And those releases were followed up by 2 months of bug-fixing to stabilize the product so it could be released to the market. We provided lots of functionality in these releases, but not always the right solutions. The long release period and the bug fixing period full of surprises, made it very hard for us to provide reliable market forecasts to our customers or the board.
I was determined to improve this painful release cycle. I organized various sessions with people from all parts of the tribe to come up with improvement actions. The business people would point out that the IT people were not able to deliver quality code. In turn, the IT people pointed out that the business people did not understand their customer journeys and provided all the wrong input. So we started to work with learning sessions; all people together who wanted to share a view, idea or perspective in order to learn from our mistakes. This was the first big step in opening up the mindset of our people. Recognizing we all had to step in to substantially change something.
I invited my newbees (working for less than 6 months in this tribe) to share their views with me and they also pointed out the lack of respect between business and IT. Also, they raised the question whether squads (teams) were actually working on the most important functionality to our clients and tribe, although it might satisfy their individual squad purpose.
At the same time I had challenges in building a target platform for Belgium and the Netherlands, where I did not have the required capabilities present in each country, and the mindset was still very much them and us. How to bring all of this together…
Helplines: Once Upon a Time…
I did not know what to do, and started looking for help. Luckily, around that time, an IT director visited our learning session and I shared my situation with him. He pointed out that he might know someone that could help, who even did a Go See of my teams previously; he introduced me to Cesario.
I ( consultant here ) came into contact with Dutch Bank while giving a talk at a meetup. My talk was about programmers in large scale development. At the end of my talk, a gentleman approached me and shared with me some challenges he was seeing in his group. He later introduced himself as the director IT at Dutch Bank Netherlands.
A couple of days later he called me. He shared that maybe I should come over and have a look in his group. This was late 2017.
I was not really interested, so I said that I would sent a proposal later this week. He answered, “hmm, I thought Agile was about Customer Collaboration OVER Contract Negotiation?”… His response made me curious and I decided to go over to Dutch Bank and have a look.
So, a couple of weeks later I went over for a Go See of a couple of days.
Understand the System Dynamics
I start many engagements with a Go See. I perform Go See sessions to show respect to the teams and leadership, and to understand how the work is working for them at the level of the larger group.
I had various conversations and workshops with the development teams and the leadership. I observed meetings, engineering practices, did pair programming, and studied backlogs to understand the work.
With all this information I create an understanding about how the work works over time, and use that systemic understanding to make recommendations.
Below you can find the observations that I can share and that are relevant to this paper.
Spotify Inspired Dutch Bank Model
The product group is called a tribe. The director is from the business and is an expert in the Business Lending market. She is called the tribe lead. The teams are called squads, and possess business (CJE), IT Engineering skills with DevOps knowledge and background. Each squad has a Product Owner (PO) that manages the squad backlog. Skill and competence development of people is the responsibility of Chapter Leads (CL). There are IT as well as business chapter leads.
Agile coaches support the tribe in working according to the standard Dutch Bank Agile way of working. The Product Owner, Chapter Lead and Agile Coach form a POCLAC. The POCLAC meets regularly to discuss problems and solutions to issues the squads might have.
You can see a visualisation of this organizational configuration below.
Local Optimization of Squads
The tribe consists of 24 squads. Some squads were dispersed across multiple sites. And most of the squads are what we call component teams in LeSS.
I also noticed that there were 24 team ‘Product Owners’. They had lots of work in understanding requirements, backlog management, coordinating between teams and team management tasks.
The team ‘Product Owners’ optimised locally. I found many examples of this. Here is one: Squad 3 needed changes in an API, and Squad 6 was planning to make those changes. Later Squad 6 decided not to make those changes and Squad 3 could not finish their work. The squads found it very hard to align with the tribe and overall product goals.
Although each squad had a clear purpose, often that purpose was not meaningful to end users. This was clear from the fact that most squads were not able to deliver end-customer value on their own. Individually these squads were able to only do a part of a complete feature. Feature dependencies existed between most squads. and ranged from around 30% upto 80%. Dependencies slow down feature development, increase queues between squads, delay the feedback loop from the market, reduce agility at the tribe level , and make it harder to be predictable at the product level. A big problem, and the problem will rise exponentially when you start adding more and more component teams.
I considered their way of working an excellent implementation of Copy Paste
scaling . A recurring mental model used for scaling Agile, that does not work very well.
The recurring problems of unreliable forecasts, poor focus at the tribe level and the inability to react to incoming ideas is strongly affected by working in such a system
Study how the work works and optimize for what you have most of
When I studied the tribe overall work that was expected to be done in the coming year, I identified 3 areas of high dependencies, that for the sake of legal reasons, we call blue, grey and orange in this paper. In the blue area we found that the work required over 7 squads full time, while 3 other squads were needed regularly.
In the graphic below you see the results of the dependency study in the 24 squad tribe. The colour of the circle indicated for how much % a squad is needed to develop end-customer features in a particular area. A complete blue circle means that a squad is needed 100% of the time in the blue area..
It turned out the blue squads 1, 2, 3, 4 ,5, 7 ,8, 18 and 21 should work together on the same product, because these squads are needed for almost every feature.
Single function managers and the POCLAC
The Chapter Leads acted as single function managers. For example there were IT chapter leads to specific technology like Pega or Java. Single function managers invite people to grow in single-skill career paths. They do not invite for mutli-skill growth of people, as is required to create adaptive teams.
Team Issues were often not discussed by the teams or with the teams directly. Instead, the issues were discussed by the Product Owner, Agile Coach and Chapter in a POCLAC meeting. This meeting takes away ownership of process, autonomy of decisions, and self-organization on how to do things, from the teams.
Exactly the opposite effect in case you want to have continuous improving teams. It was no surprise that team ownership decreased over time and ‘poclac’ activities increased a lot.
Seventeen squads that were working in feature branches. That is, they were working for the duration of weeks and sometimes months in isolation without integrating their code with the other squads. I found that there was no good reason for having so many branches other than “ this is the way things were done over here.”
Branching inhibits coordination and introduces delay, integration problems, reduces refactoring possibilities and causes long lasting, painful stabilisation phases full of surprises. When there is no Continuous Integration there is poor coordination.
It was no surprise that releases were recurrently painful and forecasts unpredictable.
Output driven development
The last observation I want to share is that of output driven development. Every quarter there was a QBR session were the squads were given Epics consisting of stories that needed to be done. Performance was tracked against a number of Epics and stories done. The goal was to deliver all the stories as promised at the beginning of a quarter. The more predictable you were the better the scores.
There are two main points to be aware of when using this approach. First, the Epics that you want done at the beginning of the quarter might not really solve the customer problem or achieve your business goals. Why? Because you might not know if your solution actually solves a customer problem, and even stronger, you might even be solving the wrong problem for your customers in the first place.
So, the goal was rather to deliver a set of Epics or solutions. Instead of achieving a specific outcome. The teams were given work to do, instead of problems to solve.
Second, with output driven development teams have no incentive to validate any of these assumptions, nor are they encouraged to do so. You run the risk of delivering a lot of solutions but for the wrong problems. The tribe used predictive planning instead of adaptive planning which is required when developing complex software.
Leadership Challenges & Organizational Design
The approach we took was two-fold. First, the leadership worked on aligning their goals. What challenges need to be addressed? Second, what organizational design is needed to deal with the challenges.
Some of the main challenges were:
- How can we become more reliable as a tribe?
- How to increase focus and alignment within the tribe?
- How to deal with to development across sites?
The insights we got from the Go See sessions led us in the following direction
How can we become more reliable as a tribe?
Reliability would probably improve is we had a better understanding of where the tribe was at any point in time with respect to their quarterly goals.
We concluded that transparency would increase if we would know every 2 weeks what was done, and was not done across at the overall product level.
To achieve this we decided to:
- Try giving the teams problems, instead telling them what ‘solution’ to implement.
- Try to have all squads take responsibility for a working product at the end of every Sprint. Instead of only feeling responsible for their part.
- Try to integrate the code from all the squads into mainline at least 2 times a day for all squads. This reduces risks of discovering bugs late in development, or even after delivery.
How to increase focus and alignment within the tribe?
Based on the Go See results we considered that focus and alignment at the tribe level would probably increase if we reduced the autonomy of the squads by asking them to reach for a common goal every Sprint.
To achieve this we decided to:
- Try to form ( the blue squads ) squads into the Customer Proposition area. Have them work from the same backlog etc; this focus increased speed and adaptability.
- Try to introduce new LeSS areas for the other squads after we verified that the first area would work.
- Try to do outcome driven planning instead of output driven planning. Do not ask the teams to deliver for example these ‘5 Epics’. Instead, ask them for example, to find a solution for reducing the time it takes to approve a loan.
- Try to gradually eliminate all branches. All teams commit to the mainline. Use branches only for product release. This increases coordination, reduces interruptions and increases speed. (At first, the people were very surprised to say the least. Doing CI with the current setup and technology seemed close to impossible.)
How to deal with development across sites?
The squads historically had worked independently across 2 sites, but now we needed to develop a single product. At each site, the people only had understanding about their specific product details, specific systems, specific customers and market dynamics. Because of all this there was plenty of duplication in systems, data and processes that needed to migrate into a single place.
So, we needed a way to further develop the product while keeping focus and maintaining reliability at the tribe level. And, we also needed to ensure that the migration of systems and data from one site to the other would keep everybody on board.
To achieve this we decided to:
- Try to work temporarily with so-called dispersed teams. This means that the quads would consist of people from both sites.
- Accept the pain of dispersed teams working distributed for the gain of growing cross tribe understanding and alignment.
So we did not use co-located team in the first period of time. Instead, we used dispersed teams with people from multiple sites to accelerate learning about cross-country systems, business processes and customers
Breaking the Rules
You can learn from the things you expect to be correct, and you can learn from doing things you expect to be incorrect. When for example you try something that you expect to work and it actually works you confirm your current assumptions and values. When on the other hand you do something you think will not work and it does work, you just learned that one of your assumptions, values or thinking patterns are incorrect.
The issue is that in general we prefer to avoid doing things that we expect not to work.
During this adoption we did lots of things I thought would not work,
So, we did not follow the conventional ideas on how to approach this. We broke a lot of ‘rules’:
- Did not educate everyone, actually did not educate anyone. Instead, people learned about the way of working while doing it. By starting every session explaining why, the goal and the tactics. By providing small workshops where people could discuss real life problems they face.
- Did not use volunteering. Instead, people got invited, and volunteering was possible after experiencing the work for some sprints.
- Did not eliminate the role of team PO. Instead, the team POs volunteered to eliminate their own role after the first Sprint.
- Did not prepare CI system before flip. Instead, we put Continuous Integration on top of the overall backlog for months. This was now possible because we moved to a single Product Owner.
- Did not use co-located teams. Instead we used dispersed teams with BE-NL people to accelerate learning about Cross-country systems, business processes and customers.
- Did not use a Scrum Master for 1..3 teams, actually we did not use any Scrum Master. Instead, we had 2 to 4 full time agile coaches ( in LeSS we call them ScrumMasters 🙂 ), and brought in help during multi-team events.
- Did not use the word LeSS. Instead, focused on the challenges. After some months I mentioned that what we are doing is LeSS, and they said, “yeah we know, we are not stupid 🙂 ”.
How do we work?
Our ( Product Owner here ) improvement Goals are:
- Improve Epic Completion ratio
- By increasing focus with 1 PBL prioritised on the highest customer value
- Deliver value in every sprint
- By cross functional/component teams to be able to deliver shippable products
- Improve happiness & Improve/broaden skills
- By investing in skills and expertise of our people to contribute to target solutions
The first step of Dutch Bank Business Lending was working with 7 squads working with one Product Owner. The squads work in the standard LeSS process. The only thing worth mentioning is the following.
All squads participate in multiple synchronous Multi-team Backlog Refinement workshops every Sprint. This increases knowledge sharing & reduces dependencies between teams. People opt-in to share what they know e.g. on Pega development.
All squads travel between countries for Sprint Review. With 2 week Sprints, this means that once a month all NL people travel to Belgium and vice versa. While we are all together we use the whole day to close the Sprint and start the next Sprint.
A typical agenda for the Sprint Review includes: Product vision, sprint goal(s), multiple demonstrations in parallel, converge to work through feedback and outlook next Sprints.
It was hard!
The squads worked for a long time on their own local piece of the product, process or customer domain. This all changed from one day to the other and brought some great opportunities for learning to see the world from a different perspective. It also was hard for people to let go of their old habits and sub optimized improvements.
Below some of our challenges that we want to share:
Why do we need to refine. I already know what I need to do?
In the first Sprints some people would find all the multi-team refinement a waste of time. They argued that they already know exactly what needed to be done. So why do we need to discuss this again with all these people that might not even work in it. This is not efficient and feels very wasteful.
I would say, “I understand that you already know all about this Product Backlog Item, but what about your team members?”
“How is you knowing everything while others do not, adding to our goal that all squads need to be able to pick any item from the Product Backlog?” If you are an expert in topic A and all your team members are experts in topic B. What would happen if we would only have topic A on our backlog? That is not what we want.
What is the plan?
Traditionally people worked with long term plans, and these plans were detailed. In this new way of working the plan for the coming quarter was detailed, but beyond that only business outcomes were planned.
I would say, “We make business impact estimations, but cannot estimate which functionality (stories) will be delivered when. The exact functionality emerges as we learn and get feedback about our functionality and the business outcomes.”
On top of that, people were not used to asked to solve a problem, but where asked to do tasks. In this new mindset, they got the opportunity to use their skills and creativity to define beautiful solutions for our customers.
This was super hard for the people in the squads, but also for the leadership outside the tribe to understand. We are still struggling with this.
Prioritize, “why do I need to work on this?”
The squads worked from the same Product Backlog. The prioritization was based on what is of most value to the tribe. This was different than before, where the backlog was prioritised to keep the squads busy and being locally efficient.
The mindset on local efficiency became clear during Sprint Planning. At Sprint Planning the squads can choose the Product Backlog Items they want to work on. Naturally the squads choose the item they are more comfortable with. The squads did not choose the items in order of prioritization. See a picture of the backlog after the squads had picked their items.
The picture shows the the squads choose the top and the bottom items to work on. They choose bottom lower value items over the middle higher value items.
When the coaches asked about this the squads said it was inefficient to pick up those middle items because they understood the lower item better.
I stayed for many times with the middle items in my hand asking the squads to pick these. Repeatedly saying that it is okay to learn and to broaden the understanding of the whole product. The goal is that any squads can pick up any item from the Product Backlog. It was hard and took a long time before the squads become comfortable with this new idea. After 1 squad had the courage to pick up these kind of items, soon other squads followed. Especially when the squads who avoided picking up items out of their expertise were confronted by the squads who did.
To much work for PO
In the early Sprints I was very eager and did everything to make it work; a period of long days and short nights. Answering questions, talking to lots of users, stakeholders, writing stories, epics, preparing meetings and so on. It was unbearable. This could not be the way to go; how could I be the PO for 7 squads?
I understood that in order to fix this, the squads needed to refine the items themselves with the customers. I needed to focus on overall planning, work with customers and stakeholders, think about the prioritization of Epics, worry about the expected outcomes of Epics, and express their acceptance criteria from a business point of view. I needed to work more at the strategic level.
This changed when we asked the people to create the storymaps to solve our top challenges themselves. The solution became their plan, and this really helped to make the refinings easier and much more effective.
Ownership and Continuous Improvement
Process improvement used to be driven by the team product owners and Agile Coach. And because of their limited reach, the improvements had been mostly local to their teams. Bigger improvements across multiple squads were much harder to realize.
The introduction of the overall retrospective changed this dynamic radically. At the end of every Sprint, squad representatives and management come together to discuss problems. The squads are completely free to try improve on anything they want. This has led to numerous improvement actions like having mob-programming sessions to share knowledge, introduce all kinds of standards, change they way the refinements sessions are done change in squads compositions and even changes to they way the overall retrospectives are done.
We have been working in this configuration for over 6 months now, and we got some interesting results as you can see below.
- Epic Completion
- Steady increase in achieving planned outcome. From 55% to 80% in 3 quarters.
- Deliver value in every sprint
- Over 50 review of valuable functionality to our users / customers. In contrast to less than 10 previously.
- Improve happiness & Improve/broaden skills
- Slight increase in employee satisfaction too. From 5.85 to 6.04.
Key Insights we want to share
The key insights we think are essential to have achieved what we have now are:
- 1 shared vision, 1 goal is very powerful
- Co-creating the product vision with the people over time.
- Repeating the product vision over and over again
- Understanding purpose increases intrinsic motivation.
- Reduction of dependencies between squads
- We have more autonomous squads because we have less dependencies between the squads.
- The work of the squads has become more meaningful because their work contributes directly to customer value.
- Create ownership, do not tell people what to do, ask them to solve problems!
- Use all the intellect that is available in the group. By setting ambitious outcome goals and have the people come up with the solution.
- Instead of making false predictions , first become more reliable.
- Multi Skilled people and cross-component feature teams increase reliability because the squads are better tuned. Measure of progress is transparent because progress is measured at the level of the feature.
- Forecasts are hard to make. But having reliable quality of the product increases the surprises during the stabilization phase.
- Continuous integration with automated tests is essential to increase predictability.
- Working in feature teams revealed that the people formerly known as the hero’s were actually preventing others from developing.
- It is not about autonomy but about tuning the teams.
- Working together with lots of teams might look the squads have less autonomy. But actually this is a false assumption. Autonomy is about being able to do your work without dependencies. Our configuration reduced the dependencies between the squads.
- A key insight is that autonomy is about how the squads are tuned with respect to each other. Moving all autonomous in the same direction requires constant tuning and being aware of the whole product.
We are still in a constant struggle and working hard to improve. An important difference is that improvement became everybody’s concern. It feels like the whole group is taking ownership of their process and taking initiatives to improve. This has made work challenging, meaningful and more fun.
About the Authors
Cesario Ramos – Guiding Large Scale Transformations worldwide – AgiliX
Mr. X – Product Area Lead at Dutch Bank.
Ms. Y – Director at Dutch Bank ( at the time of writing )
Mr. Z – IT Area Lead at Dutch Bank.
 COPY PASTE SCALING https://agilix.nl/resources/ScaleYourProductNotYourScrum.pdf
 WHY ISN’T YOUR CURRENT APPROACH TO SCALING AGILITY WORKING?