Case Study: Building Change Loan Terms Solution (Part 1)

Why We Write This 

Danske Bank transformed their ways of working by organizing work in squads that consist of employees with different competencies. Each squad belongs to a bigger unit called Tribe that contributes to the organization's business strategy. We in Buying & Owning Real Estate Nordic Tribe deliver digital processes and tools that enable and empower customers to confidently manage their home and consumer finances in Sweden, Norway, and Finland.

Change Loan Terms is one of our built solutions for the Norwegian market, which enables customers to request to change loan terms digitally. We have decided to write a series of articles describing the most relevant and important aspects of solution delivery, starting with the initial scoping and ending with the public launch, which marks the end of the first milestone in a long journey of digital transformation. The articles were written by Mindaugas Paskevicius (Frontend Cloud Development Chapter Lead) and Giedrius Slivinskas (Backend Cloud Development Chapter Lead), with inputs of people who were building the solution.

We have several purposes in mind while writing these articles:

• describe solution-building activities in a transparent and open way;

• show the building process beyond the context of one role, e.g. a business analyst would see what’s cooking on the engineering level and vice versa;

• give readers a glimpse of how does the Tribe Setup (introduced by Better Ways of Working Agile Transformation) work in practice;

• spark discussions, inspire others and get second opinions, criticism, and suggestions for improvement and continuous learning, which are two of the core values in our Tribe.
  

Problem

Our Norwegian colleagues who help our customers to change loan terms were experiencing a number of pain points, listed below:  

• Customers were requesting loan term changes via different channels (phone, email, meetings) and it was difficult to handle these requests in an efficient way,

• The information given was unstructured, often insufficient to complete a request without multiple clarifications,

• It took time until requests reached necessary employees, because request handling was different depending on the request type,

• With Covid-19, the number of requests increased and it started to get more difficult to cope with all the work in a timely manner.

This is how the initiative to digitalize changing of loan terms has been born.

Solution

If the end-goal of this initiative is to have a fully automated End-to-End process, then the initial focus should be striking the right balance between three things:

1. How to deliver something that could bring immediate value for end customers as well as for employees?

2. How to not make the solution scope overly complex so that it could be delivered in a reasonable timeframe?

3. How will our delivery support the long-term vision of automating the whole process?

As the two main problems being identified were many different channels and unstructured data, the first logical step was to tackle those.

It was agreed that the variety of different channels should be reduced to a single digital point of entry, where all changes to a loan could be made. For unstructured data, all the necessary data points for various types of changes have to be agreed on, so that this information could be provided to teams for further handling.

Going further, the next step could then be to automate the request-handling process. However, including this would greatly expand the scope and effort needed, so it was decided to first focus on the first two goals, and get back to the automation in Iteration #2.

(Keeping) Scope

When working on a new solution, it may often be challenging to keep the scope pretty much fixed for the first release and not to creep additional features in during the development process. Our product owner Monica says that usually stakeholders want to push a lot to add new requirements, and it totally makes sense from the stakeholders' point of view. Development capacity is usually limited, and you may be afraid that once your solution is built and implemented, development teams will focus on other development requests and you may have to wait one year or more for enhancements. Hence, you may want to push as many features as you can in the first release. However, Monica says it wasn't the case this time.  One of the key reasons for this was that the stakeholders wanted the solution as fast as possible (they have been waiting for it for quite a long time), and they knew that additional requests, even if small, would push the first release date further.

A common understanding of the solution scope was a key element in the building process, and it enabled fast alignments and quick decisions along the way. For example, working on text translations was a smooth ride, because, instead of a request-response type of collaboration, it was a real-time co-creation activity. Additionally, being pragmatic on both sides was also helping - when there was a question of whether to include requests for some specific loan types that are rarely used but had specific requirements, it was quickly decided to leave them out to simply save time.

Timeline and Parallel Work

The start of building a new solution can be tricky to coordinate - even if the urgency is high, you cannot allocate all people to work on the solution from day one, because there will be no defined work for everybody to do, and (or) some people need to complete previously planned work.

We started with Monica doing an introduction kick-off meeting for all teams presenting the purpose of the solution and key elements. Then she worked on defining the scope with the stakeholders from Norway (Customer Relations & Customer Guidance), while our business analyst Dovile and UX specialist Martin were working on other tasks, not related to the solution. Meanwhile, the Backend squad started to work on some technical enablers, such as creating a new microservice skeleton using Mediator pattern (which was not used in our solutions before) and investigating the best way of configuring and sending emails to employees who handle requests.

Once Monica finalized the scope, our business analyst Dovile started to work on clarifying requirements, and she worked in parallel with our UX specialist Martin. The parallel work of BA and UX paid off because the feedback loop was instant, and requirements could immediately be adjusted if some details became evident in screen design. Moreover, it also paid off that the technical backend development was already ongoing and technical boundaries were also taken into account when designing requirements and screens. For example, the initial thought was to show remaining debt and monthly payment to customers in the first screen of loans overview, but technically it would have required two separate calls to the core loans system, so we have decided to only show the remaining debt (but add interest rate type as well), and then add additional details to the next screen where loan detailed view is presented. Another example is that initially it was planned to display all customer loans, even if loan-term changes for some of the types will not be offered to customers, but it appeared that those loan types are not being received from the loans system and consequently it meant a few design changes. We also experienced some downsides of parallel work, for example, Martin said he had some stressful times when he needed to come up with designs when requirements were not yet fully ready.

Frontend squad started working on the solution a bit later - in theory, that could have been good because they could have been able to connect to already implemented APIs and start UI and experience processing layer development. However, in practice, it wasn't as smooth and it was a bit bumpy road in the first sprint of working together, we will discuss it more in the next article.

Solution testing and launch activities took place in the summer months, which was a bit challenging due to many people going on vacation, but sometimes you just don't have a choice because each year has its summer. The solution was launched in several steps and this helped to polish the solution before its public launch.

To summarize, we had a fair share of parallel work of BA, UX, and developers, and even if seemed a bit busy or even chaotic at times, we felt that it gave advantages over another approach of short iterations where BA would work first, UX would provide screens, and then developers would build, because feedback loops would have been more delayed. We also experienced some disadvantages, for example, developers have started to work on implementing design when design scalings haven't been done yet, and implementation adjustments were needed after the completion of designs.

The picture below shows the timeline of building Change Loan Terms solution by different activities and sprints.

Squads work in 2-week sprints and during this timeline, we had one Innovation Sprint, in which squads worked on new ideas and fixes that you don't usually get around doing, so this sprint was not part of the timeline.

Figure Timeline and Parallel Work. Black bars indicate full-time activity (e.g., the business analyst was fully focused on the solution, or all frontend developers were working on the solution), and grey bars indicate part-time activity (e.g., work not related to this solution was conducted during the sprint).

Learnings

• Well-organized kick-off meetings are must-have and help the whole team to understand the main objective and scope.

• Alignment with and support of stakeholders are crucial in the timeline - if decisions are taken fast, they don't block development.

• Parallel work of different roles requires mental readiness but reduces feedback loops.

• When facing deadlines, choose what to prioritize and be transparent about limitations that you choose to accept.
  
  

What is Next

In the next article, we will talk about our ways of working and how we synchronized work between frontend and backend development.