VK WorkSpace team experience
Working with cross-product features is a quest for the resilient: separate teams, independent regulations, different approaches and practices. Often in such situations, team synchronization is blocked by many factors, which inevitably affects the speed, quality of development and support of cross-product features.
My name is Taisiya Tolstunova, and using the example of the product quality assurance team in VK WorkSpace I’ll tell you what difficulties may arise when working with cross-product features and how to minimize potential problems.
The material was prepared based on my joint report with Elena Koreneva “Overcoming the Difficulties of Cross-Product Testing”.
Cross-product features
A cross-product feature is end-to-end functionality that is tightly integrated into several products at once. That is, such a function can work both in one product and in several, and can be used in several products in an end-to-end manner. From a user perspective, this improves UX (User Experience) because such features are familiar and understandable within the product ecosystem. From the developer’s point of view, this simplifies the administration and updating of features: made a change in one place and the update was rolled out to all products.
We actively use cross-product features in VK Workspace. VK WorkSpace is a communication platform for business, which includes the following services:
Thanks to the implementation of cross-product features within VK WorkSpace, the functionality for users looks the same as when working through VK Teams applicationand when working in a separate product (for example, in corporate Mail).
But implementing and testing such features is a real quest. Since the feature is cross-product, it affects several products and requires the involvement of specialists from different teams – this can provoke more than one problem.
Possible problems and our way to solve them
Two independent teams are like two rotating gears. Therefore, it is not surprising that the process of synchronizing their work without preliminary preparation is unlikely to be smooth. Moreover, the complexity of such setup increases non-linearly with an increase in the number of teams involved in working with a cross-product feature.
There can be many potential problems, as well as their prerequisites. We encountered some of them and learned to cope with them.
Coordination
We had two products that interacted to a limited extent in terms of authorization. And one day, right before the release, one of the teams brought us a two-factor authentication feature for testing, hoping that in a week it could be rolled out into production. But ce la vie: nothing ended up in production after a week.
There were several problems:
There were many coordinators for the feature. As a result, it was unclear who was responsible and who to contact with questions.
There was no full interaction between the teams. Teams are used to working autonomously. There was no sufficient level of communication to agree on the nuances of implementation or clarify certain aspects. The problem was aggravated by long responses from the neighboring team – sometimes the answer to even a simple question had to wait a day due to the low priority of one of the parties.
There was no public status for the task. We couldn’t understand at what stage of implementation the feature was now and what would happen to it: all the information was localized within one team.
To address these issues and prevent them from occurring in the future, we approached management and initiated a series of organizational changes. As a result:
A single coordinator has appeared. This is a designated technical specialist responsible for the entire feature across all products. In fact, he acts as a single source of truth who knows everything about the feature, the stages of its implementation, possible difficulties and other aspects.
The status of the task has become public. We have created a page that contains up-to-date information about the task and the stages of its implementation, which makes the process of working with the feature transparent.
We introduced the practice of regular meetings involving those responsible for tasks. This helped us establish interaction between teams and take into account the specifics of each team's work when planning tasks.
No shifting left
In the case with the mentioned two-factor authentication functionality, the problem initially was that the feature was brought to us already ready-made. Accordingly, all the implementation details remained under the hood and making any changes was difficult, time-consuming and expensive.
To eliminate such difficulties, we decided to more actively implement Shifting left practices. Now:
we receive requirements before development begins;
potential implementations are discussed with us in advance;
neighboring teams involve us in reviewing the documentation before the start of implementation, expecting confirmation from us that we have read it and have no comments.
This helped prevent situations when features that require global improvements or do not meet our requirements end up in the pre-production or even production environment.
Architecture
Initially, before building full-fledged cross-product interaction, testers were not involved in the development of the cross-product functionality architecture. This was our omission, since testers are the bearers of unique expertise who, in addition to general patterns, know bottlenecks in the product and can highlight potential difficulties in implementation even at the design stage.
For example, the lack of practice in involving testers once had negative consequences: when implementing the event notification function in the Calendar, we did not take into account that we needed to involve another team. As a result, the function worked through corporate Mail, but was not available through VK TeamsMoreover, the problem turned out to be on the side of the third team, which was not initially taken into account.
After analyzing the situation, we changed the approach: now testers are involved in the development of the architecture.
To smooth out the involvement of additional teams, to avoid problems of different values and lack of agreement on actions, we have preliminarily defined:
How detailed should the information in chats be?
in what situations are calls organized;
what additional actions are needed to achieve a single goal.
To make joint actions more transparent and predictable, we also tried to develop common Agile practices specifically for cross-product interaction. Moreover, we do not limit the range of such practices – we use everything that shows itself well in real cases.
Technique
Each team in the company is a separate living organism. Therefore, it is not surprising that each one has its own life bubbling inside: different practices, boards, processes and the stages they are divided into. There may be no intersections between teams at all. This does not mean that someone works better than their neighbors: everyone chooses a process to cover the needs of the business, and this is normal. Moreover, such a situation when building cross-product interaction is an opportunity to exchange experience and adopt the best. Such an exchange of experience helps to establish communication and better understand colleagues. But the search for compromises is still necessary.
For example, we found that we had different testing processes: some teams tested on pre-production rigs, some on production rigs. At the same time, in the context of cross-product features, it was important for us to test even before pre-production rigs: any errors in such implementations are important to fix at the earliest possible stage.
After weighing all the pros and cons, we came to the unanimous opinion that it was advisable to move the integration test to a separate stage. As a result, we deployed separate stands and agreed on temporary testing points. Thus, we received an additional stage of verification at early stages without disrupting the usual work patterns of each of the teams.
“It just happened that way historically”
Each team has its own skeletons in the closet. Sometimes even the teams themselves don’t know about them. At one time, we encountered such a skeleton precisely as part of the implementation of the mentioned two-factor authentication functionality.
After the test and launch into production, we discovered that some phone numbers simply could not be specified. As a result, some users were unable to comply with two-factor authentication requirements.
We started looking into it and found out that the problem goes back to 2013. At that time, a task was created prohibiting adding numbers with a certain prefix. And none of the teams involved in working with the cross-product feature knew what this task was and what caused the need for such a block.
In fact, it was a blocker that significantly limited our feature. The situation was complicated by the fact that it was an ancient crutch and no one understood how its fix would affect the product as a whole.
After preliminary analysis, we were able to pull out this crutch without consequences. But in order not to play Russian roulette anymore, we started to maintain a common database of old and new crutches that need to be taken into account during development.
Transparency of the result
When working with multiple product teams, it is important that deadlines and agreements are met, and the current and subsequent task statuses are clear and visible to all participants. To ensure this, it is important to record all agreements and processes for a cross-product feature, for example, using Confluence and Jira. There should be a single source of knowledge on the feature, accessible and known to everyone. This way, you can find the person responsible at any time, track the stages, understand the timing of the rollout to production, and more.
If there is no clear regulation, some processes are inevitably immersed in the Black Box, and agreements are lost or forgotten, which ultimately negatively affects the performance of the cross-product feature.
What's the result: how to live with cross-product features
Working with cross-product features is always akin to moving along a thorny road. But this does not mean that you should give up improving your own products and user convenience for the sake of your own comfort.
It is possible to structure the work process so that it is as convenient, transparent and understandable as possible for all participants.
We have collected our experience of stepping on a rake and written down our conclusions:
The more people involved, the greater the risk of encountering coordination problems. Therefore, it is impossible to do without a single coordinator. This person must be immersed in all the details of the process.
When you are just planning to develop a cross-product feature, you need to start interacting with other teams at the first stages. You should forget about the fact that you can just do it and bring it ready for approval. Otherwise, you may face the need for a long, complex and expensive refinement of the feature, and no one needs that.
There is no need to try to bring teams to common processes. It is enough to establish communications and develop simple rules of interaction within the framework of a cross-product feature. This will help to eliminate disagreements, inconsistencies and other difficulties that affect the final product.
There are no teams without skeletons in the closet. And if the team knows about them, it is better to highlight such places so as not to accidentally stumble upon them when developing a cross-product feature. In our case, this was easily resolved by creating a common database.
Most of the difficulties on the way to developing cross-product features are organizational. You may encounter all of the ones listed in the article. You may find your new shiny rake. Or you may not encounter them at all, if everyone in your company, from the manager to specialists, understands the importance of such features and why resources are needed to implement and support them.
