June 27, 2019 at 18:05As in the thrash architecture and lack of skills in Scrum, we created cross-component teams
Hello!
My name is Alexander, and I lead the 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 transformations. 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 the culture in the organization, where it is customary to reason: “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 better than our customers , we know what they need. "
Agile transformation can only happen when people themselves change in it.
I would highlight the following key fears that prevent people from changing:
Having embarked on a transformation path, we selected the first “experienced rabbits” - employees of the retail sector. 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, to put it mildly “thrash”. A huge number of applications and components, seamlessly linked by DB link, have an ESB bus, but it does not fulfill its purpose. There are also several ABS.
Before forming scrum-teams, the question arose: “And around what should the team be assembled?”. The concept that there is a product in the bank, of course, was in the air, but at a distance of inaccessibility. After much deliberation, they decided that the team should be gathered around a direction or segment. For example, “Team Loans”, which develops lending. Having decided on this, we began to come up with the 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 Scrum Master - at that time it was almost impossible to explain to CIO what the role of this wonderful person was.
As a result, after clarifying the need to launch development teams, we launched three teams:
With a set of roles:
The next step was to determine how the team would work. We conducted agile training for all team members, put everyone in one room. PO was not in the teams. Probably everyone who did the agile transformation understands how difficult it is to explain the role of PO to business, and it’s even more difficult to put it next to the team and give it authority. But we “stepped” into these changes with what was.
Since a huge number of applications were involved in the lending processes and other areas of the retail business, we began to think, who can 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 the employee is also an important thing, and getting a person to work where he does not like is quite difficult.
After analyzing the work of the business lending process and long conversations with colleagues, we still found a middle ground! So there were three development teams.
People began to divide into those who want to change, and those who do not want to. Everyone is accustomed to working in conditions of “they gave me a task, I did it, leave me alone,” and team work does not imply this. But we have solved this problem. In total, 8 out of 150 people quit during the changes!
Then the fun 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 a CRM developer. He is in 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 their 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 collected 13 development teams for all areas of business and service development. We continue the agile transformation and move to 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 changes in the product, quickly introduce new features to the market and improve the services of the bank!
My name is Alexander, and I lead the 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 transformations. 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 the culture in the organization, where it is customary to reason: “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 better than our customers , we know what they need. "
Agile transformation can only happen when people themselves change in it.
I would highlight the following key fears that prevent people from changing:
- Fear of losing power and “epaulettes”;
- Fear of becoming unnecessary for the company.
Having embarked on a transformation path, we selected the first “experienced rabbits” - employees of the retail sector. 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, to put it mildly “thrash”. A huge number of applications and components, seamlessly linked by DB link, have an ESB bus, but it does not fulfill its purpose. There are also several ABS.
Before forming scrum-teams, the question arose: “And around what should the team be assembled?”. The concept that there is a product in the bank, of course, was in the air, but at a distance of inaccessibility. After much deliberation, they decided that the team should be gathered around a direction or segment. For example, “Team Loans”, which develops lending. Having decided on this, we began to come up with the 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 Scrum Master - at that time it was almost impossible to explain to CIO what the role of this wonderful person was.
As a result, after clarifying the need to launch development teams, we launched three teams:
- Loans
- Cards
- Passive operations
With a set of roles:
- Development Manager (Tech Lead)
- Developer
- Analyst
- 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. PO was not in the teams. Probably everyone who did the agile transformation understands how difficult it is to explain the role of PO to business, and it’s even more difficult to put it next to the team and give it authority. But we “stepped” into these changes with what was.
Since a huge number of applications were involved in the lending processes and other areas of the retail business, we began to think, who can 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 the employee is also an important thing, and getting a person to work where he does not like is quite difficult.
After analyzing the work of the business lending process and long conversations with colleagues, we still found a middle ground! So there were three development teams.
What's next?
People began to divide into those who want to change, and those who do not want to. Everyone is accustomed to working in conditions of “they gave me a task, I did it, leave me alone,” and team work does not imply this. But we have solved this problem. In total, 8 out of 150 people quit during the changes!
Then the fun 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 a CRM developer. He is in 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 their 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 collected 13 development teams for all areas of business and service development. We continue the agile transformation and move to 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 changes in the product, quickly introduce new features to the market and improve the services of the bank!