We build an effective interaction between engineering and product teams.

@innubis

The reality is that any successful product must understand, be able to predict and react sensitively to the new needs of its audience. And even more - to set new trends. This inevitably imposes obligations on the engineering team, which is involved in the development of the product: engineers have to constantly dive into the product process, conduct all sorts of experiments, and at the same time maintain efficiency at a high level.

We are in Badoo with relatively small forces (in my team of 30 people) monthly deploying about hundreds of new popular features, without losing the quality of the code, planning and support. How we manage to stay "on horseback" and how we have built the interaction of the engineering team with the grocery, I will tell in this article.
')
I am sure that our experience will be of interest to other companies. And I hope that the approach that we have developed through trial and constant improvement will really help someone (and ideally will save time and effort when building processes and will give the desired result).

My name is Dmitry Semenikhin, I am the team leader of the Features team at Badoo. I have been working here for almost six years, and during this time my eyes witnessed a rapid evolution (in the context of product development) of both the team and the processes in it.

By processes in this article, I mean the system of interaction between engineering and product teams, a set of certain rules and recommendations designed to improve and simplify this interaction. But before you start to improve something, you need to decide on the tasks that we want to solve. Let's call them key values. We have developed the following for ourselves:

• Transparency . All participants in the process must understand what they and the adjacent teams do, to know for what everything is done and how.
• Speed We cannot afford to spend a lot of time on a lot of approvals, empty discussions, on "polishing" minor trifles. The path from the idea to the prototype in production should be as minimal as the required quality allows.
• Flexibility We must adapt as quickly as possible to changes in the market, be able to transform quickly, and respond promptly to any challenges.

Scheme of work 1 (startup)

I joined the team in 2012 for an innovative for those times mobile direction. We had five backend developers and one product manager (he is the customer). There were also three client teams (iOS, Android, and Mobile Web), but I’ll mostly be talking about the work of the backend team.

Task setting and planning were simple. The product manager collected requirements from the business, formulated them in simple TK, prioritized and formed a list of tasks for our team. Next, tasks were handed out to the developers, who established communication with the developers of other teams and brought their tasks to production. Why it worked at that time:

• A single list of priorities (take the top task from the list as soon as the resource is released). It should be borne in mind that any developer could work on any task. (Transparency and Flexibility)
• Ease of communication. The product manager and the business can see what the engineering team is doing, it is easy to track the progress of each task, because there are not so many of them. If something is not clear, then one phone call or chat message solves the problem. (Transparency and Speed)
• Timlid head all over. It is easy for Lida to keep in mind all the projects that his team is leading, it is easy to agree with other leads on the order, timing, etc. (Transparency and Speed)
• Understandable and convenient process. Easily configure filters and dashboards in Jira. There is one list, there are few tasks. (Transparency, Speed, Flexibility)

And we lived for a long time with such a scheme. After all, it is as close as possible to the startup-style! Everyone knows everything, everyone participates in everything. The process was as simple and straightforward as possible. "How young we were…" :)

But something went wrong

Over time, our server team has grown, and we naturally divided into groups consisting of several people. Each group was responsible for specific directions (for example, instant messenger, search, notifications, etc.), or, in terms of Jira, components. In the meantime, the product team has also grown, and we have more customers. At this point, we realized some of the shortcomings of our scheme, but by inertia we continued to live with it, solving problems with precision. And they were ...

The first problem: we could no longer guarantee the order of extracting tasks from the prioritized list, since the distribution in the list did not correspond in any way to the directions into which the team was divided. Thus, some groups could be very busy, while others were underutilized with grocery work. Because of this, the product manager had the feeling that we are working chaotically or not at full capacity.

The second problem: inconsistency of action and opacity. There was a desync in the work of different teams, as there were many participants in the process, it became more difficult to negotiate. As a result, we spent a lot of time on meetings, synchronization of team work and discussion (who should start what to do and when).

In general, all our core values ​​suffered at once.

Scheme of work 2 (planning around the head)

These problems we solved in a complex.

First, we developed an interface in which each project was divided into stages (for example, “Protocol - billing - server API - Android - iOS”), and then it was easy to see progress and dependencies. It was a kind of add-on for Jira, which allowed us to see the overall picture of the project in a format more convenient for us than offered by the built-in Jira tools. Transparency improved.

Secondly, the server team began to carefully monitor the plans of client teams and take into development only those projects that they had in their immediate plans. To do this, each client team was assigned a responsibility from the server team, who once a week updated the plans of “his” client team and notified the others about them. As we have seen from our own experience, it is very risky to develop the server part in advance - it is very risky: priorities can change, and the requirements for the feature. Transparency and speed improved.

Thirdly, knowing the plans of client teams, we could more competently organize our work, seeing, for example, that some groups are overloaded and others are not. In this case, we either asked the product managers to change priorities, or redistribute the work of the meju. For example, one development team could take a part of the tasks of another, overloaded group, to ensure the right order of priorities. Flexibility has become more flexible. :)

Scheme of work 3 (vertical)

As time went on, our team continued to grow. And if our division in directions (components) in an engineer allowed us to scale fairly easily, then the product team could no longer exist as a monolith, so it, too, was divided into directions (verticals). For example, there were: Comms, Revenue, Core, Next gen applications. That is, the product team is divided in accordance with the business goals of the company, which is logical. As a result, instead of one list of priorities, we received four conditionally independent at once. Within each product line, a prioritized list of tasks was formed and “descended” to us.


Fig. 1 Four independent product verticals (streams) form task lists for the entire engineering department. Next, the tasks fall into the appropriate development teams in accordance with their specifics.

In addition, for each vertical we had an approved quota of engineering resources. Relatively speaking, vertical A receives this month 30% of the time, B - 20%, C - 40%, D - 10%. Next, we created the simplest statistics, which took cuts in Jira on product tasks in progress, divided them vertically and built graphs. We looked at these charts and decided which vertical we need to pay more attention to.


Fig. 2 Tracking the actual cost of development resources for each of the verticals to maintain the correct proportions.

The scheme is quite working and in general complied with all our values, if not for the fact that we almost always experienced (and continue to experience) a lack of engineering resources (by the way, yes, we are looking for talents! ). This led to the fact that the product team did not understand at what point a project from a certain vertical would be taken into development.

Considering the allocated quota for the vertical, as well as our internal engineering division by components, it could turn out that the task in third place in the vertical could hang there for a very long time, or even not be completed at all, since the group responsible for this project was overloaded.

I will explain. In this scheme, the product team perceived our department as a monolithic resource of more than 30 people, for which, for example, one of the verticals “drops” ten new tasks. But in practice, all these ten tasks could fall into one development group, since they all belonged to the same technical direction for which this group is responsible. Suppose there are only five people in this group. In this case, it is obvious that the team could not cope with such a flow of tasks in a reasonable time, but for the product team this was by no means obvious.

Under these conditions, bad things began to happen. Food managers began to press engineering leads about their “stuck” projects, randomly sort their lists, moving individual tasks to the top lines of the list and “pushing” others. Lida was under constant stress, trying to please everyone and at the same time trying to somehow leave resources for support and technical projects. As a result, many food projects were implemented, but for some reason this did not bring satisfaction.

It was impossible to live like this anymore! Summarizing, I will once again outline the problems that we had at that time:

• The complexity of planning. For a large number of tasks in the pool, it was impossible to say when they would be taken to work.
• As a consequence - the opacity of the development process. Other teams simply could not understand when it would be possible to begin work on their part of the project, since it was not clear when the task on which it depended would be completed.
• Several nervous situation in the team (and in the engineering team, and in the grocery). Everyone was unhappy with everyone.
• The shift in focus on product development to the detriment of support and technical debt due to attempts to satisfy the needs of the product team.

And we took action.

Scheme of work 4 (current)

First of all, we decided to improve transparency by opening our internal structure to the product team. Now they can see that five people are responsible for one application functional, and only three after the other. Such an open process has a nice bonus: respect for the resources of colleagues. The members of the product team see who is busy and how long will be occupied, and take this into account when planning their tasks.

Next, we introduced a clearer weekly planning based on the formation of separate backlog for development teams. The product team (all verticals together) every week forms and prioritizes the list of tasks in accordance with their belonging to a specific group. Moreover, they agree among themselves which of the tasks is more important, and the engineering leaders no longer need to find a balance in order to please all the food verticals. Further, the group leader, taking into account the capabilities of the team and the complexity of the proposed tasks, takes as many tasks from the top of its list as its group is able to start solving this week. After that, a single list of tasks taken for all groups is shown to the product team, if necessary, adjustments are made to it (something is added, something is replaced). After this, the plan is considered approved.


Fig. 3 The product team independently forms backlogs for each development group. Engineering leads take in the work only those tasks that they are able to begin to solve in a week.

It should be noted that in our case the plan for the week is a list of tasks that we undertake to begin to solve in the week. The deadline for completing the task is displayed in the due date field and is set at the moment when the developer starts to work on the task (I will write a little more about due date below).

What we got in the end:

• Transparency. Everyone can see what tasks are planned, can assess the current situation and deadlines. All this is presented in a convenient form for all.
• Flexible and simple planning. The period of "week" was chosen for a reason. In our conditions, this is the optimal time period, which allows you to keep the focus on really important things.
• Calm working atmosphere. There is an approved plan, and we are working on it. There is no need to wait for sudden unplanned tasks (he was a little bit: they, of course, need to wait, but not in such numbers as before).
• Freedom to maneuver. Lida, freed from pressure, which was when using the previous scheme, can plan technical projects, quietly reserve resources for bug fixing and technical debt.

Are there any downsides? Of course. For example, now the product team should do things unusual for it: to take part in planning the resources of another team. From now on, the engineer for it is not just a “black box” where team members fill in new tasks and wait for them to be completed - now, when forming the task log, you need to take into account the functional fragmentation of the engineering team in order to ensure the even distribution of important tasks into groups. Fortunately, Jira’s built-in tools make this relatively easy to do.

Also for the product team it is still not always clear why the lead took only three tasks for the week out of the ten proposed. Now we just verbally explain what lies at the basis of such a decision, but I would like to simplify and visualize it. For example, you can pre-estimate the size of all new tasks. This will allow more efficient use of developers' resources. It is quite possible, if the product manager knew that the development of a certain task would take so much time, he would not offer it, but would make a choice in favor of several simpler ones, but in total they would have a greater effect for the business.

Despite all this, in my opinion, the advantages of this scheme are much greater than the minuses. Therefore, now we are using it, while not ceasing to analyze problem areas in order to soon finalize our interaction mechanism.

Important addition

In order not to distract from the description of the schemes of interaction between the engineering and product teams, I decided to put in a separate chapter a few points that are extremely important to mention.

Due date

We set due date for all product tasks and monitor compliance with this parameter. The developer, having received a new task, must first analyze it in detail, evaluate its work, the work of adjacent teams, risks and dependencies - and only after that set the date when, in his opinion, the ticket will be produced. Yes, this is not a mistake. Not the date when he will finish writing the code, and not the date when he will give the task to QA, but the date when the task appeared in production.

Why this is important and how we came to this was described by Ilya Ageev in his article. In a nutshell: we have every developer - this is a little project manager who conducts his task from beginning to end. And it is he who is responsible for the result and deadlines. If due date is not respected, we analyze the causes and try to ensure that this does not happen again in the future, or we search for bottlenecks in the system and fix them. The developer also briefs all interested on how the project is progressing, what difficulties arise in the process, how and by whom it is blocked in the special field of the Situation ticket.

Project teams

Despite the planning and availability of a standard task development process based on the functional division of teams (each department is responsible for its own part of the product), such a mechanism is often not flexible enough and effective. The most striking example is the experimental tasks: when you need to develop a certain functionality, the type and logic of which is not fully understood; when you need to quickly make the original prototype, and then make a lot of edits, improving the product (and it requires the simultaneous work of several teams at once).

In such cases, for the period of the project, we create a cross-functional project team in which there are resources from all the necessary units. And it often works “bypassing” standard processes. If required, separate planning and development processes are introduced for this team, as well as a scheme for interaction with the product team.

Afterword

If you have a small team in which everyone can do everything and everyone is aware of everything, no special interaction mechanisms are required. Everything works this way!

But as soon as you start to grow, there is a need to better coordinate the work of the process participants, there are overhead costs for communication. At this point, it is already necessary to introduce some kind of processes like weekly meetings, stand-ups, syncs, etc.

When the project grows to the point that even within one department any employee cannot replace any, fundamental changes are needed, processes that will take into account your structure and internal specifics.

That is why we did not take ready-made methodologies like Scrum and Kanban, but use some intermediate version with its own features and add-ins. And we still continue to improve our processes and are not going to stop: as you can see, there are still enough problems.

And how did you solve and solve the indicated problems? Please share in the comments.

Thanks for attention!

PS This Saturday at the Moscow office of Badoo will be held Techleads Meetup . There are no empty seats, but you can watch the broadcast on our YouTube channel . Join us if you are interested in the topic of building processes in a company and management in IT!