Our team develops credit and guarantee products for legal entities. The direction is young, the first issues began in 2018. We checked-in and studied the market, launched an overdraft, a loan to increase turnover and bank guarantees. The plans were to launch a loan against a contract, mortgage loans and other products.
Symptoms
Our process from quickly starting grocery mechanics has been piling up crutches. We put up with them and, as you might guess, once noticed that the tasks for the processes began to be developed for too long. This was reflected in the constant transfer of releases, tasks were not completed on time. Bugs were piling up affecting a small, specific segment of customers.
There were situations when the release for the next task, which had already been moved for two months, was again postponed indefinitely. At the same time, the release of the overdraft feature broke bank guarantees. There was a desynchronization of product understanding. The developers considered things important that the business team didn't even pay attention to. On the other hand, the key features of the products remained unknown.
To get out of the crisis situation, a working group was created, which was faced with the task of making “fast and good” from “bad and long”. For ourselves, we set goals to improve performance and reduce the number of bugs.
Problems
Having delved deeper into the team's processes, we found a tangle of problems that could not be solved separately, they required an integrated approach:
- old technology stack;
- long and crooked kanban process;
- business climbed into the internal affairs of development;
- the development team was losing interest in the project;
- general toxicity.
I will tell you in more detail how this was expressed.
Old technology stack. Our process was written in IBM ODM, a system with a number of features that got in the way of the team. They were described in detail by our architect Denis Kotskinin the case of a neighboring project (although there was IBM BPM, but in general everything is fair). Separately, I note that there are no specialists on the market with experience in this system.
Long delivery process. Officially, we positioned ourselves as a kanban team, but the processes looked like a cross between waterfall and scrum. The legacy of waterfall development is that business, development, and test only communicate in the Jira card. Everyone had a clear thought: "I have done my part of the work, my hut is on the edge."
We didn't come to kanban right away. At the very start, we used Scrum with sprints, which shows itself better on young projects. Then they realized that it was morally difficult for the team to transfer tasks from sprint to sprint, and switched to kanban. Then it became clear that no one knows how to work with the input stream, the development cycle began to appear. It manifested itself in the fact that tasks from the business were received once a week, then the team evaluated them, it became clear that nothing was clear, and the task was sent off for the next week. At the same time, in words, we did kanban and looked for bottlenecks.
I understand that the ideas of Kanban and Scrum do not contradict each other and there are examples where a combination of methodologies shows good results. But I want to emphasize that there was a radical position of pure kanban. The large number of returns from test to development also greatly slowed down, which signaled the low quality of the task at the early stages.
Role model violation. Business analysts were engaged in architecture - they came up with a technical solution to the problem. This led to the fact that they often refused to conduct deep discovery in favor of elaboration and specification of the solution, and this hack, coupled with a weak architecture, repeatedly slowed down the development.
Loss of interest by the team in the project.A talented, ambitious, young team. Pure startup. After launching and scaling, growing pains began. Constant pressure from the business, the complexity of development due to the lack of refactoring, the accumulated internal problems, the backlog for months ahead led to banal fatigue and burnout.
Because of all of the above, the atmosphere in the team soured. Problems were fixed on retro, but not solved, and wandered from week to week. The general toxicity went off scale, any dialogue on work rolled into mutual reproaches.
What have we done
Frankly speaking, at the beginning we only understood that we needed to rewrite the process from scratch to get rid of crutches and strengthen the team with experienced developers. Six months later, I can name two more things that helped us:
- Rebuilding the kanban process. Thanks to the Tinkoff Biznes delivery center, which promptly delved into our issues and helped to adapt Jira.
- Business and IT synchronization. Here we were driven by the belief that the team should have a good understanding of the product, and not just perform the tasks that will bring it.
In the end, rewriting the process solved the technology stack problem and helped to get rid of crutches. The rethinking of the kanban process helped rebuild the role model and reduce the number of returns, that is, increased the speed of delivery of tasks to the product. A number of synchronization activities and rethinking of the current formats have straightened out the general atmosphere.
Part 1. Rewriting the process
So we started to rewrite the process from IBM ODM to Camunda. The reasons for choosing Camunda are described in Nikolay's article nshipyakov...
In application processes, we use such a term as stage - a logically closed part of the process, with a clear meaning for the client, for example, “Collecting documents” or “Signing a loan agreement”. The first task for us was to launch a contract loan. We realized that the logic of the three stages is specific to it, and the rest are no different from the analogous stages of a circulating loan. Actually, we wrote three stages of a new product on Camunda. In the future, the whole stage was rewritten when a business task appeared for its serious change.
A natural question arises: how did we negotiate with the business? It is clear that rewriting an already working functionality takes longer than modifying it on the old engine. Everything turned out quite simply: colleagues were ready to invest in a new process, because they saw how cool it worked on a neighboring project (and hello again, DenisKotskin). At the same time, the development time on the new engine was not much longer, since we began rotation: the burned-out guys moved to other projects, hired employees with experience in developing and designing business processes to replace them.
Part 2. Changing the order of conducting tasks
When changing the development process, we relied on the following guidelines:
- There should be no steps that are not reflected on the board.
- Technical expertise should be given to the team.
- The team must understand how the task affects the business.
By changing the kanban process, we have identified new stages that previously implicitly went through the development stage: this is architecture and the meeting of three amigo. Naturally, architecture is not carried out on minor changes, but we try to hold a meeting of three amigos for any task. Nastya has an article about the "Three Amigo" methodTravieso... I want to say a special thank you to Nastya: her training in Agile testing inspired us to make many changes within the team.
The team receives data on the value of the product in the format of a user story and an assessment of the impact of the task on the product. It can be hard to tell the bluff of savvy business customers. For example, the rating “This rule is important, will be checked on all applications” is much less informative than “We conducted an analysis, the rule will refuse 10 additional applications per week”. Therefore, before submitting a task to development, I validate the quality of the written value, as a representative of the business team who shares the values ​​of the developers.
We also gave up practices that didn't work for us. For example, now we rarely do retro, only when necessary - when the need to discuss something accumulates. This happens about once a month. It is imperative that we solve the problems indicated in retro, since it is important that each team member sees positive changes on the issues that weigh him down.
We stopped using storypoints and team assessment of the task - we work with due dates that we receive from the business, and depending on them, we manage the input flow. On large tasks that are done for a couple of months, we carry out decomposition: it makes it possible to make a kind of check-points and increase the accuracy of due. To monitor progress, we periodically meet and discuss whether we are on time. If we see that it is not, we adjust the input stream and take fewer small tasks. As for the accuracy of hitting the deadline, I can only say that for our current major task, we fit into due.
Regarding the redistribution of roles, we strengthened the team with an architect and a second systems analyst. The business team tries to clearly explain what is needed in the task, what value it carries, but does not advise or get into the inner workings of the development. I also look after the business team.
Part 3. Synchronization of IT and business teams
We use several formats to synchronize business and developers.
Demo by task. This is a meeting of all interested - portfolio analysts, risk department, marketers and IT specialists - with a discussion of the value, problematic problem and technical solution.
An important meeting where you can find errors missed at the discovery stage and have time to fix them. Also, the manager who leads the task does not know for sure which company processes will be affected by the release. With us, such publicity allows us to prevent situations when changes in the process break, for example, analytical reports.
Retro on task.At this meeting, we discuss the problems of developers and customers that they encountered during the development of the problem. We conduct it after the post-release analytics - when the passions have subsided and everyone is ready for a constructive dialogue. After finding out the reasons, we form points of growth and a cloud of ideas, which we will try in the future.
We conduct lectures on products in the format of an educational program and subsequent discussion. Their goal is to immerse the IT guys in the business context. For the collected feedback in the form of a survey with the most general wording "Rate today's lecture", the average rating is 8.5 out of 10.
Outcome
Six months later, we rewrote more than 80% of the processes, launched a loan against a contract using a completely new engine. The team atmosphere has improved and we have become more efficient. To verify this, we conducted a survey of the team and took statistics from Jira.
The survey asked about the atmosphere in the team, the quality of specifications, development and architecture, the quality of communication with the business. According to the results of the survey, the average score of the guys who have been in the project for more than six months rose from 6 to 8 points out of 10. Unfortunately, the survey is not completely honest, since it was conducted after the changes. The figures given refer to the beginning of the year and the beginning of July. So it is fair to say that the situation in the team has improved, but it cannot be said how much.
Productivity (number of tasks per day) has doubled during this time. Naturally, not at the expense of decomposition: we agreed in advance on certain standards that we adhere to.
The number of returns from test to development has slightly decreased. That is, with a multiple increase in the number of tasks displayed for prod, the number of returns did not increase. This indicates an improvement in the quality of the task development at the discovery and architecture stages. The number of bugs found on production has not changed.
What have we learned
Now I will formulate a few ideas that the team and I have learned from our experience. If you have similar problems in your teams, I hope they will help you too.
- , . — . , — , . — .
- , , , , , . , .
- — , , . , , discovery .
- . one-one-, , . Shoom3301, .
- : — , IT — . , .