Our work

BMS CS KBM: Codebase revitalization.

BMS Corporate Solutions GmbH oversees the corporate customer segment of Germany’s cooperative banks.

In collaboration with their architect, we identified and solved issues together, contributing to improving the codebase’s quality.

Performance Acceleration

Performance Acceleration

Living the Scrum life

Living the Scrum life

Two companies one team

Two companies one team

Architectural decisions

Architectural decisions


What does the client do? What industry are they in?

BMS Corporate Solutions GmbH – a subsidiary of Atruvia AG and BMS Consulting GmbH – is responsible for the entire corporate customer segment of the cooperative banks in Germany.

Initial situation.

What was the initial state?

We joined the already established team, which consisted of two frontend and two backend developers, two business analysts, two architects, a scrum master, and a product owner. We additionally brought two frontend and two backend developers.


The tech stack consists of Angular (frontend) and Java Spring (backend).


We were responsible for the part that deals with organizing appointments/meetings of bank employees and their customers.


We implemented services from the previous team into our ownership.


Since BMS CS nurtures an Agile methodology, our team has been working within the Scrum framework for two years now.

Problem space.

What problem did we want to solve?

BMS-CS inherited a less-than-ideal codebase from another company. We partnered with their architect, identifying and solving issues together, to enhance the overall health of the codebase.

The first problem we identified concerned the speed and reliability of the existing applications and services. With response times often exceeding five seconds and numerous unsuccessful requests, their reliability was significantly compromised.


While BMS-CS and ProductDock already employed Agile methodologies, the real challenge lay in growing together as a single Scrum team. Our goal was to optimize our collaboration to deliver maximum value for our customer.


What did we do? What technologies did we use? How long did it take?

To solve the first problem, we needed to identify tech issues. Since we are just a small part of a very large company, we could not change the tech stack, but that was all right since the tech stack was not the problem.

We solved the problem with slow response time by changing the way the backend authorizes frontend requests. It took us several sprints to make this possible, and it was an effort of the whole team.


Refactoring most of the client interface is another improvement we made, and it was a gradual process. To enhance the quality of the codebase, we adopted several clean code practices such as SOLID principles, avoiding redundant code (DRY), and eliminating unnecessary features (YAGNI).


Also, we implemented the Onion architecture in some parts of the backend system to improve the system’s testability, maintainability, and dependability.


Furthermore, we introduced unit tests as a must, which led to average test coverage of 70%. Automatic linting was applied in all our artifacts, which is the usual practice at ProductDock.


We adopted an agile mindset as a team, incorporating the Scrum process into our daily operations. For instance, this meant preparation for every refinement event, ensuring all team members understood the objectives of each feature under discussion. Our daily meetings became concise and productive, and planning events were used optimally.


Over the course of two years, our team increased in size a lot. So, to make our daily work more efficient and have more focus on specific business contexts, we eventually split into two teams.


Currently, our team consists of the following roles:


Team members from the client side include a product owner, Scrum master, QA tester, business analyst, a frontend developer, and a backend developer.


As for the ProductDock members, they include three full-stack developers, one backend developer, and one frontend developer.


What was the outcome? What did we learn?

In the end, all the things we implemented greatly increased customer satisfaction. Moreover, we were able to drastically reduce the number of reported bugs and ease up the development process, which enabled us to onboard new team members much easier in terms of initial project setup.

All the changes we introduced increased our team’s confidence and enabled us now to be responsible for making architectural decisions as well.


The outcome of our team’s improvements (enhanced quality, performance, and new functionalities) are highly significant to our stakeholders as well. With our ability to plan sprints effectively, we can now complete all the tasks outlined for a sprint (90% of the time). Moreover, we’ve become adept at responding to changes in requirements and handling incidents in production.

Our ProductDock colleagues are the most kind and funny people. They are ambitious and open to new approaches/ideas, and I highly appreciate working with them. It feels like we all work for the same company, which is probably due to them really taking responsibility for their work.

Chrissy Adamus

Scrum master at BMS CS