From monoliths to modular teams

    Large companies often grieve over the problem of adaptability and maneuverability. More precisely, almost from the complete absence of both of them.

    Imagine: all platform teams are busy with one feature, and the business has an urgent requirement to do something else or adjust the functionality that is already being developed. And at this moment work on one feature stops and work on another begins. At the next moment, new requirements from the business appear, and the feature remains unfinished. Developers are offended and the business is suffering.



    Here's another situation: the API is changing, you need to urgently run to the backend department to find out the details, then back to the fronts (iOS / Android / web). Further, after discussing your corrections with the fronts, you need to go back to the back and speak our requirements. It was very exhausting, lost the time of teams, an individual developer and the nerves of all interested people.

    My name is Valery, our team was engaged in QIWI Wallet for iOS. But it was always necessary to keep communication with other teams, otherwise a complete desync would result. As for our inconveniences, the business always goes forward and gives freedom for experimentation. Therefore, the question arose of changing the existing structure. A favorable environment for testing our ideas for change was scrum. Every two weeks, we inside the platform could edit the course so that it was at least somehow coordinated with other teams. It took a long time to test theories. From a month to six months. What options have we tried:

    Feature oouner


    One person from the team was appointed responsible for the feature for the next sprint. This person spent part of his time with designers and with a feature from an other front-line team (the back-up decided not to use the feature-ower), figuring out the pitfalls and subtleties of the upcoming work, he agreed with the backend about the contract. He also monitored all changes to the backend and business. And everything seems to be fine. No one runs in a panic, except for this person who takes the blow of a changeable environment on himself. Everyone pacified for a moment.

    But happiness continued exactly until the feature of the OUNER got sick exactly before his sprint. And the whole illusion of appeasement was dissolved, 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 at several meetings in a row. But the main reason is the variability of APIs and contracts, the change in sprint goals, and it’s good if it changes only on the first day of the sprint. But usually all the same, the changes fell over all two weeks. Bottom line - the goals are not met, the guys are processing, the business is suffering.

    Chats


    One of the non-standard options was the creation of chats. A separate chat was created for each feature. In addition, there were also chat rooms of teams where problems were discussed. And also a general chat specifically for problems where all the teams were. At first, the problem seemed to be resolved.

    But the chats quickly multiplied, and, you know, it became a burden. When a problem appeared, it became unclear where to look for information - either in the chat on the profile section, or in the chat on 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-tim


    Then a grocery store came and offered to try the feature-tima format. What does this mean: two developers are taken from each platform (iOS, Android, web, backend) and two testers) and a new team is formed.

    This approach was supposed to solve several major problems, in addition to coherence and speed of release of releases:

    Autonomy
    The team that goes to meetings together is as independent as possible from others. The main link from external dependencies is the product.

    A quick check of theories
    After all, before the entire wallet team did some new functionality and it happened that this very cool functionality did not enter users. It turns out that the whole development sawed unnecessary 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 affects 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 product tasks. Now, when changing the contract, you don’t need to run around the departments and look for responsible ones, there is also no need for a bunch of confusing chats, just poke a developer sitting nearby. Meetings are held all the featured, where representatives of all platforms and QA are immediately present.

    Questions are solved in words in a couple of minutes and no one experiences the same pain. In addition, another great benefit for the business is if the feature didn’t reach users, then only one feature of the team (at the moment out of three) will be spent, and not the entire development, as it was before.

    As a result, we managed to achieve the following advantages:

    • Autonomy from other teams.
    • The maximum flexible development, we can safely change course, if the software requires it.
    • Quick and easy problem solving.
    • A quick test of feature theories.

    I hope this example helps you solve communication problems among teams. If you have other cool options, then I'm waiting for feedback).

    Thanks.

    And we will soon have a mitap for iOS developers.

    Also popular now: