As in the conditions of thrash architecture and lack of skills in Scrum, we have created cross-component teams
Hello!
My name is Alexander, and I lead the IT development at UBRD!
In 2017, we, at the center of the development of information technology services at UBRD, realized that the time had come for global changes, more precisely, agile transformation. In the conditions of intensive business development and rapid growth of competition in the financial market, two years is an impressive period. Therefore, it is time to take stock of the project.
')
The most difficult thing is to change our thinking and gradually culture in an organization where it is customary to argue: “and 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 customers better , we know what they need. "
Agile transformation can occur only when people themselves change in it.
I would highlight the following key fears that prevent people from changing:
Having taken the path of transformation, we chose the first “experienced rabbits” - employees of the retail sector. The first thing we did was redesign the inefficiently working IT structure. Having invented the target concept of the structure, they began to form development teams.
The architecture in our bank, as in many others, to say the least “trash”. A huge number of applications and components, monolithically connected to each other DB link, there is an ESB bus, but it does not fulfill its purpose. There are also a few ABS.
Before you form a scrum team, the question arose: “And what should the team be gathered around?”. The notion that there is a product in the bank, of course, was in the air, but within reach. After much thought, it was decided that the team should be assembled around a direction or segment. For example, "Team Loans", which develops lending. Having decided on this, we began to invent a target set of roles and a set of competencies necessary for the effective development of this direction. 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 commands:
With role set:
The next step was to determine how the team would work. We conducted agile-training of all team members, put everyone in one room. PO in teams was not. Probably, everyone who did the agile transformation understands how difficult it is for a business to explain the role of PO, and even harder to put it next to the team and give 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 could be suitable for the role? The developer of one stack of technologies, and there you look - and you need a developer of another stack of technologies! And here you have found those who are needed, but the employee’s desire is also an important thing, and it’s quite difficult to make a person work where he doesn’t like it.
After analyzing the work of the lending business 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. Everyone is used to working in the conditions of “they gave me the task, I did it, leave me alone,” and teamwork does not mean this. But we also solved this problem. In total, 8 out of 150 people left 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 CRM developer area. In the team he is, 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 started 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 don't tell anyone about it).
Today we have 13 teams of development in all areas of business development and services. We are continuing the agile transformation and are entering a new level. This will require new changes. We will redesign teams and architecture, develop competencies.
Our final goal: to respond quickly to changes in the product, quickly bring new features to the market and improve the bank's services!
My name is Alexander, and I lead the IT development at UBRD!
In 2017, we, at the center of the development of information technology services at UBRD, realized that the time had come for global changes, more precisely, agile transformation. In the conditions of intensive business development and rapid growth of competition in the financial market, two years is an impressive period. Therefore, it is time to take stock of the project.
')
The most difficult thing is to change our thinking and gradually culture in an organization where it is customary to argue: “and 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 customers better , we know what they need. "
Agile transformation can occur only when people themselves change in it.
I would highlight the following key fears that prevent people from changing:
- Fear of losing power and epaulets;
- The fear of becoming unnecessary for the company.
Having taken the path of transformation, we chose the first “experienced rabbits” - employees of the retail sector. The first thing we did was redesign the inefficiently working IT structure. Having invented the target concept of the structure, they began to form development teams.
The architecture in our bank, as in many others, to say the least “trash”. A huge number of applications and components, monolithically connected to each other DB link, there is an ESB bus, but it does not fulfill its purpose. There are also a few ABS.
Before you form a scrum team, the question arose: “And what should the team be gathered around?”. The notion that there is a product in the bank, of course, was in the air, but within reach. After much thought, it was decided that the team should be assembled around a direction or segment. For example, "Team Loans", which develops lending. Having decided on this, we began to invent a target set of roles and a set of competencies necessary for the effective development of this direction. 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 commands:
- Credits
- Cards
- Passive operations
With role set:
- Development Manager (Tech Lead)
- Developer
- Analyst
- Tester
The next step was to determine how the team would work. We conducted agile-training of all team members, put everyone in one room. PO in teams was not. Probably, everyone who did the agile transformation understands how difficult it is for a business to explain the role of PO, and even harder to put it next to the team and give 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 could be suitable for the role? The developer of one stack of technologies, and there you look - and you need a developer of another stack of technologies! And here you have found those who are needed, but the employee’s desire is also an important thing, and it’s quite difficult to make a person work where he doesn’t like it.
After analyzing the work of the lending business 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. Everyone is used to working in the conditions of “they gave me the task, I did it, leave me alone,” and teamwork does not mean this. But we also solved this problem. In total, 8 out of 150 people left 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 CRM developer area. In the team he is, 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 started 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 don't tell anyone about it).
Today we have 13 teams of development in all areas of business development and services. We are continuing the agile transformation and are entering a new level. This will require new changes. We will redesign teams and architecture, develop competencies.
Our final goal: to respond quickly to changes in the product, quickly bring new features to the market and improve the bank's services!
Source: https://habr.com/ru/post/457962/
All Articles