From monoliths to modular commands
Big companies often grieve at the problem of adaptability and maneuverability. More precisely, almost from the complete absence of both.
Imagine: all platform teams are busy with one feature, and business has an urgent requirement to do something else or adjust the already developed functionality. And at this moment work on one feature stops and work on another begins. In the next moment, there are already new demands from the business, and the feature remains unfinished. The developers are hurt and the business suffers.
')
Here's another situation: changing the API, you need to urgently run to the backend department to find out the details, then back to the front (iOS / Android / web). Next, after discussing your adjustments with the fronts, you need to go back to the back and talk about our requirements. It was very exhausting, the time of the teams, the individual developer and the nerves of all interested people were lost.
My name is Valery, our team was engaged in QIWI Wallet under iOS. But it was always necessary to keep communication with other teams, otherwise it turned out a complete dissynchronization. As for our inconvenience, business always goes forward and gives freedom for experiments. Therefore, the question arose about changing the existing structure. Scam was a favorable environment for testing our ideas on change. Every two weeks, we could edit the course inside the platform so that it was somehow coordinated with other teams. To test theories was given a lot of time. From a month to six months. What options we tried:
One person from the team was appointed responsible for the next sprint feature. This person spent some of his time with the designers and with the feature ower from another front-team (back decided not to use the features of the hunter), figuring out the pitfalls and subtleties of the work ahead, agreed with the backend about the contract. And also watched all changes of backend and business. And everything seems to be fine. No one runs around in a panic, except this man, who takes the blow of a changeable environment on himself. Everybody was pacified for a moment.
But the happiness continued exactly until the feature of the ouner fell ill just before his sprint. And the whole illusion of appeasement vanished, and we returned to where we started.
Representatives of different platforms were invited to groom one platform team. It became a little better, but the guys did not like (from the word at all) to sit in several meetings in a row. But the main reason is the variability of the API and contracts, a change in the goals of the sprint, and it’s good if it changed only on the first day of the sprint. But usually, all the same, the changes fell over the entire two weeks. The result is that the goals are not fulfilled, the guys recycle, the business suffers.
One of the non-standard options was the creation of chats. For each feature, a separate chat was created. In addition, there were more chat rooms where problems were discussed. And also a general chat specifically for problems where all the teams were. At first it seemed that the problem was solved.
But chats quickly multiplied, and, you know, it became a burden. When a problem appeared, it became unclear where to look for information - whether in the chat by profile section, or in the chat by refactoring the network client or replacing the user information module. As a result, it became only more confused. Again I had to run between departments.
Then came the grocery store and offered to try the feature format. What it means: two developers are taken from each platform (iOS, Android, web, backend) and two testers) and a new team is formed.
This approach had to solve several major problems, in addition to the coherence and speed of release of releases:
Autonomy
A team that goes to meetings together is as independent as possible from others. The main coherent from external dependencies is the product.
Quick Theory Check
After all, before the whole team of the wallet did some kind of new functionality and it happened that this coolest functionality did not go to the users. It turns out that the whole development sawed the useless things and the budget went nowhere.
The whole team understands what “product development” is.
Features are made or business requirements arrive, and the developer does not always understand why, why, and who needs it.
The whole team influences the product. Up to inventing new features
As a result, everyone liked this approach, and at the moment we have 3 independent teams that are engaged in their own product tasks. Now, when you change the contract, you do not need to run around the departments and look for those in charge; there is also no need for a bunch of confused chats; you just need to poke a sitting developer next to it. Meetings pass all fichatimy where representatives of all platforms and QA at once are present.
Questions are solved in words in a couple of minutes and no one experiences the same pain. In addition, another big business benefit is that if a feature suddenly doesn’t go to users, then only one feature of the team will be wasted (at the moment out of three), and not the entire development, as it was before.
As a result, we managed to achieve the following advantages:
I hope this example will help you in solving communication problems among the teams. If you have other cool options, then wait for feedback).
Thank.
And we will soon have a mitap for iOS developers.
Imagine: all platform teams are busy with one feature, and business has an urgent requirement to do something else or adjust the already developed functionality. And at this moment work on one feature stops and work on another begins. In the next moment, there are already new demands from the business, and the feature remains unfinished. The developers are hurt and the business suffers.
')
Here's another situation: changing the API, you need to urgently run to the backend department to find out the details, then back to the front (iOS / Android / web). Next, after discussing your adjustments with the fronts, you need to go back to the back and talk about our requirements. It was very exhausting, the time of the teams, the individual developer and the nerves of all interested people were lost.
My name is Valery, our team was engaged in QIWI Wallet under iOS. But it was always necessary to keep communication with other teams, otherwise it turned out a complete dissynchronization. As for our inconvenience, business always goes forward and gives freedom for experiments. Therefore, the question arose about changing the existing structure. Scam was a favorable environment for testing our ideas on change. Every two weeks, we could edit the course inside the platform so that it was somehow coordinated with other teams. To test theories was given a lot of time. From a month to six months. What options we tried:
Feature player
One person from the team was appointed responsible for the next sprint feature. This person spent some of his time with the designers and with the feature ower from another front-team (back decided not to use the features of the hunter), figuring out the pitfalls and subtleties of the work ahead, agreed with the backend about the contract. And also watched all changes of backend and business. And everything seems to be fine. No one runs around in a panic, except this man, who takes the blow of a changeable environment on himself. Everybody was pacified for a moment.
But the happiness continued exactly until the feature of the ouner fell ill just before his sprint. And the whole illusion of appeasement vanished, and we returned to where we started.
General grooming
Representatives of different platforms were invited to groom one platform team. It became a little better, but the guys did not like (from the word at all) to sit in several meetings in a row. But the main reason is the variability of the API and contracts, a change in the goals of the sprint, and it’s good if it changed only on the first day of the sprint. But usually, all the same, the changes fell over the entire two weeks. The result is that the goals are not fulfilled, the guys recycle, the business suffers.
Chat rooms
One of the non-standard options was the creation of chats. For each feature, a separate chat was created. In addition, there were more chat rooms where problems were discussed. And also a general chat specifically for problems where all the teams were. At first it seemed that the problem was solved.
But chats quickly multiplied, and, you know, it became a burden. When a problem appeared, it became unclear where to look for information - whether in the chat by profile section, or in the chat by refactoring the network client or replacing the user information module. As a result, it became only more confused. Again I had to run between departments.
Feature
Then came the grocery store and offered to try the feature format. What it means: two developers are taken from each platform (iOS, Android, web, backend) and two testers) and a new team is formed.
This approach had to solve several major problems, in addition to the coherence and speed of release of releases:
Autonomy
A team that goes to meetings together is as independent as possible from others. The main coherent from external dependencies is the product.
Quick Theory Check
After all, before the whole team of the wallet did some kind of new functionality and it happened that this coolest functionality did not go to the users. It turns out that the whole development sawed the useless things and the budget went nowhere.
The whole team understands what “product development” is.
Features are made or business requirements arrive, and the developer does not always understand why, why, and who needs it.
The whole team influences the product. Up to inventing new features
As a result, everyone liked this approach, and at the moment we have 3 independent teams that are engaged in their own product tasks. Now, when you change the contract, you do not need to run around the departments and look for those in charge; there is also no need for a bunch of confused chats; you just need to poke a sitting developer next to it. Meetings pass all fichatimy where representatives of all platforms and QA at once are present.
Questions are solved in words in a couple of minutes and no one experiences the same pain. In addition, another big business benefit is that if a feature suddenly doesn’t go to users, then only one feature of the team will be wasted (at the moment out of three), and not the entire development, as it was before.
As a result, we managed to achieve the following advantages:
- Autonomy from other teams.
- Maximum flexible development, we can safely change the course, if required by the software.
- Quick and easy problem solving.
- Quick verification of feature theories.
I hope this example will help you in solving communication problems among the teams. If you have other cool options, then wait for feedback).
Thank.
And we will soon have a mitap for iOS developers.
Source: https://habr.com/ru/post/459196/
All Articles