When the situation changes dynamically, we react agilely. About cooperation with one of the largest banks in Poland during the pandemic

The previous year was in many respects a breakthrough for banks and technology providers operating in the financial industry. The functioning of the former largely depends on factors such as the possibility of direct contact with customers, a stable economic situation or applicable law. With the advent of the pandemic, there was a need to immediately adjust existing banking processes and systems. New regulations and restrictions resulting from the lockdown appeared overnight, stationary service was reduced to a minimum, the possibilities and needs of consumers, whose financial situation in many cases became less predictable, changed. The consequence of all this was the remodeling of the customer service method and the transfer of most of the services offered to the online channel.

Many years of cooperation with clients allow us to constantly keep improving communication and the system of project work. However, the current conditions, and above all the requirement to react quickly to changes and remote work, have given us a push to introduce further improvements.

Building a new model of cooperation with the bank

We started talking to one of our clients, belonging to the group of leading banks in Poland, over two years ago about the use of agile methodology in the implementation of joint projects – the idea came up to work with the Scrum model. Initially, the bank’s assumptions and expectations were defined, and VSoft analyzed them in the context of the capabilities of the production team. We started slowly, with the pilot, not being aware then how useful this approach would be in some time.

Covid appeared at a time when our teams were already working in the agile model, which was a form of a test for us, checking whether the implemented processes would bring the expected effect. System modifications had to be introduced almost in real time, and the priorities of delivered modifications changed very quickly. Today we can see that we came through this baptism by fire mainly due to a change in the way of communication and approach to the role that the bank plays in the entire process of implementing a dedicated solution. In the traditional model, the role of the contracting authority ended when the project was commissioned. Now, we have formed one team and we are pursuing a common goal for a given sprint.

What were our most important assumptions?

The goal that we set for ourselves when rebuilding our cooperation model was to quickly deliver business value in developed systems, understood as new application releases, adapted to the changing internal and market needs. At the time of declaring the pandemic, the rapid implementation of changes in business processes related to subsequent anti-crisis shields also became such a value. We had to implement subsequent system elements much more often and act dynamically. The determination of the people responsible for business decisions at the bank turned out to be important for the success of our cooperation. Both sides saw an advantage in this shift in delivering a better product. So, we had a clearly defined goal and determination to act.

The change in the way of cooperation, although needed and expected on both sides, was not obvious at first and raised many concerns. First of all, it required both teams to be more open, more frequent information exchange, and readiness to constantly verify their progress. Even from a formal point of view, it was necessary to provide appropriate tools and access, establish a scheme for creating a product development plan (backlog), develop new processes. The challenge was to define the conditions that must be met in order for the work on a given element of the system to be considered as completed; for example, that a given functionality must be tested, documented, presented, uploaded to some environment. In order to adapt our current way of operating to the new conditions, we had to remodel the teams on both sides, appoint people who care about the constant flow of information and strengthen the roles responsible for the product.

Team synchronization on several levels

It is also worth mentioning that our synchronization takes place on many levels – the team consist of business and IT representatives on both sides, and we work in 4 different Polish cities. We are bound by a product understood as a change in the system or a service that we are to provide, because although the solutions we create are mainly used by bank employees, they also affect customer service. For example, in a situation where a Call Center employee makes a call to a customer, we want the conversation to be held at a high level. We made sure that a Call Center agent had a 360-degree view of the client, i.e. current data and a system that allows them to generate all the necessary documents, in accordance with the applicable requirements. Our team implements many internal processes and business goals that serve to provide the client with useful and reliable information.

Transparency, inspection, adaptation!

We introduced the Scrum methodology, focusing on its three pillars: transparency, inspection and adaptation. Transparency required openness on both sides, now working in one team. In the business context, this means a clear definition of what is a priority in product development, and on the part of the supplier it is important to transparently present the costs of implemented changes. Daily meetings, sprint reviews, joint retrospections give us the opportunity to constantly verify the status of works and their level of advancement. We all have an influence on the selection of priorities and the order of execution of individual stages. Thanks to such openness, we look at the project business goals from the perspective of one team, which greatly facilitates their implementation.

It can even be said that we introduced the agile methodology in an agile way in several iterations. The implementation of the new cooperation model means constant inspection and adaptation – in the next sprints we will look at the effects, verify the entire process and decide what should be improved.

What has the transition to cooperation in the agile model brought us?

The advantage of the agile model is that, instead of performing point-by-point of what has been commissioned, we focus on solving a given problem and delivering real value. As it turns out, the implementation of one functionality often means that another one has to be implemented in a different way or is even redundant. Working in a scrum team allows us to better understand and be agile, thanks to which at the present time we can act dynamically and quickly react to legislative changes. New product versions are implemented through the smallest possible change packages in order not to disrupt the entire development cycle, and at the same time deliver the expected business value as quickly as possible. In the traditional approach, assuming that, in the event of changes, the entire process must be rebuilt from an operational and procedural point of view, and implementations take place after many months – it would be much more difficult for us to adapt the systems to the new requirements.

The new model of cooperation has blurred the line between the ordering party and the supplier. Currently, everyone in the team knows what the purpose of the sprint is and what work there is to do within it, regardless of their affiliation to the organization. Previously, we worked in isolation, we shut down for a few months, after which the final product was delivered for business testing. The bank knew what part of the project was being implemented but was not informed in detail about the status of tasks and the area on which VSoft was working on a given day. Now we are asking questions right away, and reviews of the emerging product and tests are being carried out on an ongoing basis. We communicate according to a set plan, thanks to which we do not waste time unnecessarily, which is particularly important in the context of remote work and team dispersion. We are able to verify on an ongoing basis whether what we deliver is going in the right direction and whether it is in line with business requirements. We carry out the main releases of the system much more often, an example of which is the implementation of credit holidays, taking place only a few weeks from the moment of announcing such a possibility.

We are on the right track

We accelerated the machine, ready to react to changes in the environment at any moment. We raised the quality of products which, due to the ongoing inspection, better meet the bank’s needs. We still have to stick to the chosen direction, we are responsible for the implementation of the main assumptions of the project and the implementation of subsequent versions of the software, but we divide our work into smaller stages, carried out together within one team. We still see a wide horizon, but we have the ability to quickly respond to feedback, both from the bank’s customers and system users. And also, see ourselves, because the current approach of the client and VSoft to cooperation is subject to subsequent minor modifications after each sprint.

He has over 20 years of experience in the IT industry and knows IT projects inside out. He has participated in their implementation both as a project manager, consultant, and manager. He has been with VSoft since 2008 and currently, as the Director of Debt Collection Development, is responsible for projects for the largest Polish financial institutions (e.g. PKO BP SA, mBank SA, Alior Bank SA, EFL SA) as well as for developing products in the debt collection area (VSoft Collection) and carrying out tasks in the field (VSoft Mobile Workforce).

Zobacz również

See also