How we created cross-component teams in the conditions of trash architecture and lack of skills in Scrum

Hi!

My name is Alexander, and I lead IT development at UBRD!

In 2017, we at the UBRD Information Technology Services Development Center realized that the time had come for global changes, or rather, agile transformation. In conditions of intensive business development and rapid growth of competition in the financial market, two years is an impressive period. So it's time to take stock of the project.

The most difficult thing is to change your thinking and gradually change the culture in an organization where it is customary to argue: “who will be the boss in this team?”, “The boss knows better what we need to do”, “we have been working here for 10 years and know our clients better We know what they need."

Agile transformation can only happen when the people themselves change in it.
I would highlight the following key fears that prevent people from changing:

• Fear of losing power and "shoulder straps";
• Fear of becoming irrelevant to the company.

Having embarked on the path of transformation, we chose the first "experienced rabbits" - employees of the retail direction. The first step was to redesign the inefficient IT structure. Having come up with the target concept of the structure, we began to form development teams.

The architecture in our bank, as in many others, is “thrash”, to put it mildly. A huge number of applications and components, monolithically interconnected by a DB link, have an ESB bus, but it does not fulfill its intended purpose. There are also several ABS.

Before forming scrum teams, the question arose: “What should the team be built around?”. The notion that there is a product in the bank, of course, was in the air, but out of reach. After much deliberation, we decided that the team should be assembled around a direction or segment. For example, "Team Credits", which develops lending. Having decided on this, we began to come up with a target composition of roles and a set of competencies necessary for the effective development of this area. Like many other companies, we took into account all the roles except the Scrum Master - at that time it was almost impossible to explain to the CIO what the role of this wonderful person was.

As a result, after explaining the need to launch development teams, we launched three teams:

1. Кредиты
2. Cards
3. Passive Operations

With a set of roles:

1. Development Manager (Tech Lead)
2. developer
3. Analyst
4. Tester

The next step was to determine how the team would work. We conducted agile training for all team members, put everyone in one room. There were no POs in the teams. Probably everyone who did an agile transformation understands how difficult it is to explain the role of PO to business, and even more difficult to put him next to the team and give authority. But we "stepped" into these changes with what was.

Since there were so many applications involved in the lending processes and other areas of the retail business, we began to think about who could fit the roles? The developer of one technology stack, and there you look - and you need a developer of another technology stack! And so you found those who are needed, but the desire of an employee is also an important thing, and it is quite difficult to make a person work where he does not like it.

After analyzing the operation of the lending business process and long conversations with colleagues, we still found a happy medium! So there were three development teams.

What's next?

People began to divide into those who want to change and those who do not. Everyone is used to working in the conditions “I was given a task, I did it, leave me alone,” and teamwork does not imply this. But we have solved this problem. In total, 8 people out of 150 quit during the changes!

Then the most interesting began. Our cross-component teams began to develop themselves. For example, there is a task for which you need to have skills in the field of CRM developer. He is on the team, but he is alone. There is also an Oracle developer. What to do if you need to solve 2 or 3 tasks in CRM? Teach each other! The guys began to transfer their competencies to each other, and the team expanded its capabilities, minimizing dependence on one strong specialist (by the way, in any company there are supermen who know everything and do not tell anyone this).

Today we have 13 development teams for all areas of business and service development. We continue the agile transformation and reach a new level. This will require new changes. We will redesign teams and architecture, we will develop competencies.

Our final goal: to quickly respond to product changes, quickly bring new features to the market and improve bank services!

Source: habr.com