De Volksbank is the fourth largest bank in the Netherlands. The bank was formed two hundred years ago from regional savings banks. Today, de Volksbank focuses on consumers, independent entrepreneurs, and small and medium-sized enterprises. The bank operates mainly in the areas of payments, savings, and mortgages.
In 2021 a new four-year strategic agenda was introduced focusing on growth by strengthening customer relationships and further increasing the banks' social impact. To realize this ambition, a transformation was initiated that aimed at implementing a uniform agile way of working with independent, integrally responsible customer journey teams. The new strategy should make the bank more customer-centric and enable them to get better, faster, and more effective at delivering value to customers.
The transformation impacted the whole bank. In March 2022, about 3,000 people faced either a change of work, a change of team, and/or a change in the way of working. In the new structure, the bank was split into 14 "Hubs". These are value areas with P&L responsibility. Each hub is responsible for a specific customer journey. A Hub is set up integrally, which implies that each hub contains business, IT, and operations. The entire organization "flipped" to the new model in March 2022.
This case study analyzes the transformation journey using Org Topologies™ Scans and focuses on the Business Banking Hub. It covers three organizational design phases:
-
Org scan of the pre-agile setup before August 2021.
-
Org scan of the 2022 dVM pilot.
-
Org scan of the current layout per February 2023.
We will clarify the stages with OT maps using the following symbols:
More explanation and background information on Org Topologies™ that help to understand this case study can be found here and here.
1. Pre-transformation setup before August 2021.
The department "Business Banking" was divided into three sub-departments: Operations, Business Lending Sales Support, and Customer Onboarding. These departments were focused on servicing business customers. A single team "monitoren en verbeteren" (monitor and improve) was responsible for product development. This was the department's R&D team. The picture below is a detailed view of the Business Banking department in deVolksbank prior to the transformation.
Of the 10 people in "monitoren en verbeteren", 6 were tasked to improve the operational workflow of the three operational teams. They had task scope, no product vision, and no value-based prioritization of work. They were working on improvement requests given to them by the operational teams. These requests did not necessarily have high customer value.
They were working as individuals on unprioritized tasks (three operations groups with different requests). They did not have the skills or authorization to make software and configuration changes in the banking systems.
Their work was restricted to:
-
specifying changes requested by the operational teams,
-
assigning them as tasks to technical teams somewhere in the adjacent IT group,
-
chasing progress.
Working as individuals on unprioritized tasks (three operations groups with all kinds of change requests) makes them a Y0-level group on the OT map.
The queue of work was huge due to the long waiting times for the work in progress. Larger and more complex initiatives were hard to implement and took many months, sometimes years to complete. Tasks belonging to these initiatives got stuck in the worklists of teams in the IT department due to unclear decision processes. The people were used to working in an environment where asynchronous communication via email requests was the norm. They were spending most of their time lobbying in IT to get their requests prioritized and negotiating with a vast landscape of stakeholders. A huge amount of time was wasted waiting.
The other 4 people worked as a Scrum team focusing on New Business Lending products. The subgroup's work was specifying and accepting changes in collaboration with an external software company that developed a New Business Lending product. This team specified customer-centric features for the vendor to develop. The team and their PO were decomposing the customer requirements into tasks to hand them over to the vendor's development teams. This makes them an analyst team for the external developers, archetype A1 in "the speculation department" on the OT map.
The New Business Lending team did not suffer from the bank's IT dependencies but had 100% dependency on their external vendor and they had some dependencies on business stakeholders ("Brands"). They were able to deliver value much faster than the teams with internal IT dependencies.
The developers at the vendor were processing tasks for multiple clients. The vendor did not have dedicated teams per client but had two groups of developers working on specific parts of the product.
2. Pilot with feature teams 2021-2022.
Prior to the bank-wide adoption, a new self-invented model (based on team topologies and Spotify) called "dVM" (de Volksbank samenwerkingsModel) was piloted in the Business Banking department. It is noteworthy to mention that this transformation initiative was driven by the Business side of the bank, not by IT, which is more common.
The people working in the R&D team "monitoren en verbeteren" were placed into four groups, each focusing on a specific customer journey. Each group contained one R&D team and one or more service teams. The R&D teams focused on developing products and the service teams kept their focus on daily operations, serving the customer. There was a tight feedback loop between them. The operational teams were important stakeholders, providing valuable customer feedback. Each R&D team had its team PO, prioritizing work on value.
The following groups were created:
-
The Customer Onboarding group: everything related to smoothly welcoming new customers.
-
The New Business Lending Group: building new business lending solutions.
-
The Business Lending Maintenance Group: Supporting existing business lending solutions.
-
The Bloxx group: developing an approach allowing business customers to configure their own service and product catalog
Each R&D team was formed with cross-functional business people. Each team was able to address a full range of business problems (features) related to their domain but they had no technical expertise. This makes them A1-level teams (analyst teams, or "the speculation department"). The backlogs contained customer-centric features instead of service-oriented tasks.
The fact that the R&D teams did not have IT capabilities was a problem because most of the changes they were working on required changes in IT systems. Some teams were able to do no-code changes, but all 'n all, their technical capabilities were limited.
Although still low on the Org Topologies™ map, this setup was experienced by the team members as a huge improvement because now:
-
they were working full-time in a steady team,
-
they were working on the specification and delivery of customer features,
-
they were working on high-value work because work was prioritized on customer value.
At the same time, having limited capabilities combined with end-to-end responsibilities was frustrating. They were wasting time chasing their changes to be delivered. We gradually improved this situation by extending their (technical) capabilities. This desire for autonomy was not appreciated by the surrounding organization. Don't forget this was only a very small pilot in a very big bank, so not surprisingly, the team's appetite for mandate, capabilities, and speed was causing resistance in the remainder of the bank.
The New Business Lending team continued working with the external vendor. In the beginning, this made their life relatively easy since they had limited dependencies on the technical infrastructure and IT teams of the bank. However, the number of teams at the external vendor had grown and now were organized as component teams: Each vendor-component team had a team "PO" managing their team's backlog. Coordinating the work across the other vendor teams was difficult and slowed down the development process. An additional complication was that the external vendor was not solely focused on delivering the bank's requirements but they were also productizing the requirements to market them to other customers. This makes total sense, but it was not helping the bank. In summary, from the bank's point of view, the vendor's business model and organizational design had a negative effect on the quality of service.
The other three teams were depending heavily on the bank's IT teams. The IT departments worked as component teams (Y0 and Y1 archetypes). Due to the high number of technical dependencies and the lack of support for the new feature teams, the Customer Onboarding PO got completely stuck. She had to split customer requirements to feed the IT component teams, she had to fight to get her work prioritized, and she had to bend over backward to find a way to get her changes integrated across multiple release calenders. Not a job you would envy...
The Bloxx team was fortunate because they were the first team to have developers in the team. However, there were some startup problems here too. The developers in the Bloxx team were working under the strict guidance of the bank's PEGA group. This group had a strong architectural drive and was focused on building centralized and reusable solutions for the whole bank. The PEGA developers were telling her how to change the specifications so the solution could fit into the PEGA architecture. It was the world upside down: the Bloxx PO found herself being a lobbyist trying to get the PEGA developers in her team to build what she needed.
One thing all teams had in common was their dependence on "the brands". The bank exposes its services in the Dutch market using four distinctive customer-facing brands. These brands had different and conflicting requirements for the solutions built by the four R&D teams. The brands were powerful: they were deciding on requirements and approved or rejected the changes created by the R&D teams, often on the technical level.
Customer Onboarding tried to get around this problem by adding a brand specialist to their team. This person was working as a proxy on behalf of all brands. In practice, this did not work because the brand specialist's decisions were overruled by other (brand) stakeholders. The dedicated teams were able to deliver in a regular Sprint cadence, which was much faster than before (weeks instead of months). But their mandate was not respected by the unchanged organization. In addition, the contradictory demands of the business stakeholders, and the complex IT environment were frustrating them.
These were the most important learnings from the pilot that helped to improve the dVM org design:
-
Feature teams with a PO to prioritize work on value and the operational teams' focus on servicing the client resulted in faster delivery of better solutions and better service to the customer.
-
Reducing the power of the stakeholders (i.e. brands) by clarifying the R&D team's mandates is required.
-
Reducing the influence of (middle) management by repurposing their role in the service of the teams is needed.
-
Teams should be bus-dev-ops teams by adding all technical capabilities to the teams required to deliver "Done".
-
Clear responsibilities and capabilities of the feature teams attract stakeholders who are in need of the capacity to get things done and try to feed their changes into the feature teams. This was unexpected behavior that actually proved this initiative was successful.
-
Creating feature teams creates much resistance in the organization surrounding these teams. Gradual change is more complex to manage.
3. De Volksbank SamenwerkingsModel (dVM) in Feb 2023.
The pilot setup with R&D teams and service desk teams (operations) close together in groups was implemented in the whole bank. All four Business Banking R&D teams gained autonomy by growing their technical capabilities. Some reached A3 (autonomously working end-to-end on customer journeys) and most were A2 (incomplete teams working on customer journeys, not end-to-end).
The majority of the dependencies on the brands have been resolved by moving product responsibilities of the brands to the feature teams in the Hubs. The brands now have teams that focus purely on work like marketing and campaigning, not banking product development. The separation between roles and responsibilities is clear: the R&D teams have the mandate and the brand teams are stakeholders to them.
Most of the dependencies on IT have been resolved. Two of the R&D teams now all have the technical capabilities they need to work autonomously. The solution to remove the technical dependencies was achieved by adding developers to the teams. The POs determine what is most valuable, not stakeholders like the architecture group via the (PEGA) developers.
The New Business Lending team's dependencies on the external vendor were not resolved. The vendor has added a "first contact" proxy team to better serve de Volksbank. The proxy team provides lo-code/no-code solutions, is a single point of contact, and handles coordination with the vendor's internal component teams. The bank and the vendor collaborate on further reducing lead times. The proxy team operates at the feature(set) level and is narrowly specialized in analysis (A1 Archetype).
The teams inside a value area (Hub) coordinate using OBEYA. The same practice is used to align with teams in other hubs. The Business Banking Hub Lead says that the implementation of the dVM model was very successful in creating strong autonomous teams. Alignment between all teams inside the hub using OBEYA has proven to be pretty successful too, but there are challenges in resolving cross-hub initiatives. Higher management has a tendency to fall back to old patterns to manage cross-hub problems (instead of trusting the Hubs to self-organize). On one hand, this is due to a lack of experience using OBEYA for that purpose. On the other hand, the Hubs suffer from local thinking. The Hub leadership teams should be more aware of the recurring dependencies between Hubs (and teams) as an indication that the org design can be improved.
Conclusion
Did the new org design make Business Banking more customer-centric and get better, faster, and more effective at delivering value to customers? It definitely did. Further improvements will be achieved by eliminating remaining dependencies, re-evaluating the current org design and improving the OBEYA for better cross-Hub collaboration. We are happy that the Business Banking Hub POs perform experiments with cross-team collaboration (applying practices from the higher B-level).
The dVM design was intended to be an evolutionary model. The OT Scans (TM) can serve as a guide to monitor the progress of the bank's journey to further improve its organizational design. We recommend each department (Hub) plots a current and future state map. This will increase our understanding of why things currently work or do not work, and will enable us to find the root causes and best possible solutions for improving the management of cross-hub problems, resolving remaining impediments, fixing staffing problems, etc.
Acknowledgments
We want to thank the following people for investing their time in creating this case study with us:
-
D. Karacan (PO New Business Lending)
-
J. Verhey (Hub Lead Business Banking)
(C) 2022, Alexey Krivitsky and Roland Flemm. Org Topologies™.