Hello, Habr! As I promised in the previous post , I continue to introduce you to Delivery Club Tech. Today we will talk about product transformation.
Coincidentally, my arrival in DC in October 2018 was marked by a total restructuring of all processes in the team. At that moment, the IT department, and indeed the entire company, faced new challenges. It was clear that the old processes did not meet the new requirements. They mainly concerned the decline in Time to Market.
It is about these changes, new challenges, a new team structure, how we work without project managers and technical analysts, and the approaches to product development that I want to tell you today.
In October 2018, I took the position of Head of Consumer. This was the beginning of my journey to Delivery Club. It was necessary to assemble product teams within the direction, describe the processes, formalize them and scale them to all other areas. In addition, the task was to derive performance metrics for teams and develop a recruiting framework from scratch.
Team Features
The most important challenge was to achieve predictability and transparency from the development process. The situation was complicated by the fact that there were no performance metrics at that time. But what was certain: the releases did not happen periodically, and their composition was clear only at the time of the release itself.
Another problem was that the teams were not formed around the product. This complicated communication with the business, since the same developer could participate in completely different projects, there was no clear focus on a specific task. Therefore, at first it was decided to rebuild the structure of the IT department and move from platform teams to product teams.
With the platform approach, backend people were sitting separately, front-endrs were sitting separately, and each team had a team leader who distributed tasks. The obvious shortcomings of this structure: the developers were not immersed in the process and the product, they were not interested in the common goal, the teams had a different focus, and there were no dedicated resources for the product either. As a result, the developer was defocused, the goals remained unattainable. Even if by some miracle it was possible to achieve the goal, then due to the lack of communication between product managers and stakeholders, it often turned out not what was originally planned.
The first thing that was decided to do: one team - one product. Resources are allocated, that is, the team performs tasks only for this product and no other. Teams working on similar products shape the direction of development. The first transformation resulted in 4 directions:
- Consumer
- Logistics
- Vendor
- Internal
The second thing it was decided to do: assign a product manager to each team. He is also one of the team. The product manager develops a strategy for product changes, forms product metrics that the team focuses on, and sets sprint goals.
As a result, we got the following cell: "Product Manager - Team Lead - Dev - QA". We include backend and front end developers as developers, but there are also teams without fronts. Frontenders are either Web Angular and JS, or iOS / Android.
Now each team has an average of 5 ± two people. Why is that? We did not come to this formula at once. Our statistics show that this is the composition of the team that allows you to achieve the most predictable result. That is, the team is able to take on enough features to make significant changes in the product, but at the same time the complexity of planning remains lower than it would be with more people. That is, the planning error becomes minimal.
For a while we experimented with roles within the team, we had mobile development team leaders (iOS / Android) and a backend team lead. But we ended up with a matrix structure:
- One team lead (as a rule, someone from the backend), he has QA, backend and frontend managers directly under his supervision.
- product- « — — QA».
- — . . , QA- , CI/CD, QA- .
- - , .
- .
Another feature of ours: we do not have project managers and technical analysts. This was originally the case in Delivery Club, and we decided that we would not change it. Remember we had a problem with the teams focusing on the product? So why create middlemen between the team and the product manager? It is important for us that teams, first of all, care about how their features affect the end user, and not just close tickets in Jira. To do this, people need to immerse themselves in context, domain, business, and even product metrics and financial metrics.
As a result, the dialogue between the development team and the product manager is ongoing. Developers not only take a list of tasks from the product manager and leave to develop all this, but they can come to him in a couple of hours and say, for example, "Hey, we can make the button here a little simpler, but a week faster", show it on the numbers, and the product manager will say OK.
Thus, the technical team performs the task of technical analysis, assessment and decomposition independently, and then, together with the product manager, plans a sprint. For this to work, we start the sprint, as it were, a week before it starts. This is the next section.
Sprint development and planning
Pre-Planning
A week before the start of the sprint, the product manager brings cases and design, answers the question "What needs to be done?" The technical team decides how it will do it and when it will be ready.
To do this, the team has a week, during which the team lead, developers and QA get together, discuss technical details, carry out decomposition, and reset by planning poker for evaluation. During this period, QA makes a list of test cases, which will then be tested.
Planning
Once the team has done the decomposition and assessment, planning begins. All tasks are divided into 8 hours. To count the number of tasks in a sprint, we multiply the number of employees by 80 hours of a two-week iteration, and the result is multiplied by a focus factor of 0.8.
Further tasks are beaten in buckets, there are only three of them:
- Product 60%
- Tech debt 20%
- Support 20%.
Let me give you an example. We have a team of 3 backenders. This is 80 * 3 * 0.8 = 192 useful hours. We will spend 116 hours (60%) on product development, 38 hours on Tech debt (20%), and 38 hours on Support (20%).
Grooming
On Monday we schedule tasks, and in the middle of the sprint, that is, a week later, grooming takes place. We call grooming analyzing the results of the first week and deciding whether we have time to reach the sprint goal or something should be cut off. If the goal is achieved, then the product manager presents plans for the next sprint at the same meeting, and the whole cycle repeats.
Demo
The logical conclusion of the sprint is the Demo, where we invite all development teams, stakeholders, business colleagues and even the head of the Delivery Club.
Colleagues responsible for the release prepare presentations, talk about the achievements of the sprint and the difficulties that have been overcome. We share a product story and insights on how new features will benefit the user.
This is an important day for the whole team!
Retro
For us, retro is a way to improve efficiency. First of all, we look at the metrics of the team's performance, how successfully we closed the sprint. We check the ratio of tasks in the status done to those that were taken at the beginning of the iteration, and fix this data by bucket.
For example, in Product we took 20 problems and finished 17. Therefore, the success rate for this bucket is 85%. Good progress in product development for us is an indicator of 90% or more. If it's lower, we discuss at Retro how we can improve this metric.
Sprint work
We are often asked about code review and how testing works. Everything is pretty standard here.
The day starts with a stand-up. For 15 minutes, the team discusses what they did yesterday and what they will do today.
We use Jira Flow and Git Flow to work on tasks, we have an Atlassian stack. There is also a Scrum board with columns to do - in progress - ready for code review - ready for QA - ready for life - done.
When the developer has prepared the code, he makes a branch with the current issue number in Jira - this is a feature branch. He also sends it to a pull request in Bitbucket. The developer needs at least two approvals. We also have integration with Jenkins, if the build is green, then you can merge. The tech lead and the team lead have the rights to merge. Sometimes you need to prepare a unit-test for a pull request. And sometimes we deliberately do not write them if we know that these are non-critical business areas, an uncritical domain or an experimental feature, and we can then cut it out.
When everything is slick, we send it for testing. A testing engineer writes autotests or runs test cases manually. Depends again on how critical the domain is. And then deploy.
We can say that this process works like a clock. But in fact, at this moment there is constant communication within the teams. The main focus is the sprint goal and the release on time. To achieve the goal, we can either discuss product changes or revise the technical implementation. All this happens while working on tasks - it is always a dialogue between developers, team lead, product manager and QA.
Development directions and structure of the IT department
In the process of transformation, we came to a new structure of development directions. As you remember, at the very beginning we wrote about four. Further, it became clear that for high-quality and timely implementation of goals, two more areas need to be identified. Thus, there are now 6 of them:
- Consumer is all about custom products: website and mobile apps.
- Logistics - about logisticians, couriers and delivery.
- Vendor - about integration with our partners (restaurants / shops).
- Internal - call center and support.
- R&D - solve science-intensive tasks.
- Platform - improving the architecture and platform as a whole.
Each direction has its own range of tasks and its own difficulties.
Consumer
The priority of this direction is the user's happiness. The main product metrics are here: retention, order conversion rate, consumer NPS. From a technical point of view, it is important for us that all data is sent quickly. In this direction, perhaps, the biggest highload, as we work directly with the end user. And there is also a huge number of microservices, there are most of them here.
The main products are a website, including a mobile version, as well as applications for iOS and Android. The two main streams are grocery delivery and restaurant delivery. Technological stack plus or minus like everywhere else: PHP, Go, Postgres, Redis and Memcache for cache, Kafka for asynchronous communication.
Logistics
The task of this direction is to ensure fast delivery of an order to a hungry user. In addition, we are developing an interface for dispatchers who, if necessary, help couriers with manual control.
One of the main challenges in logistics arises when the number of orders grows, and with it the load on the system. To cope with the loads, you need to make quality changes to the architecture. In addition, food delivery is very different from delivery of, for example, office supplies, clothes, books, and more. Everything is a little simpler there: we made a route sheet, planned it and went.
With food delivery, such a number will not work. We are all on demand, the situation changes every 5-15 minutes. When it starts raining or snowing, demand always rises. And when it's sunny outside and you don't want to stay at home, demand decreases. On holidays and weekends, the demand profile differs from weekdays. The traffic situation and congestion also make their own adjustments, especially in those areas where auto / motorcycle couriers prevail. Morning, afternoon and evening hours have different demand profiles.
This demand migration is tracked by our monitors. If the demand has decreased, we change the search results, give out more relevant offers in the "Promotions" section. To improve relevance, we connect ML-models that make sorting personalized both for the user and for the logistic zone in which we are observing a change.
One of the main applications being worked on in logistics is the Rider App. It is an Android application in which couriers see where to pick up an order and where it should be delivered.
Vendor
This area works with our internal partners: restaurants and shops. Or rather, with their managers, who manage the menu through their personal account and react to statistics in the search results.
Thanks to the collected data and statistics on orders, we have a good understanding of the target audience and the characteristics of restaurants. We work with them in partnership and give them a tool that helps them better understand who their customers are and enable marketing mechanisms. We also help restaurants develop pricing optimization models, understand which dishes are best to display at what moment and in what sequence.
Another product that is being worked on in the Vendor direction is a dashboard into which orders for the kitchen fall. The kitchen accepts the order, sees its composition, determines how to prepare it and, in fact, prepares it. When the order is prepared, the kitchen confirms this in the app and transfers the order to the courier. And then the courier works with the Rider App.
Internal
This area is responsible for the tools for our call center, which provides user support. In fact, this is the "admin area" for everything related to orders. The operator can help the client, give additional information about the current status of the order, make adjustments to the order before it is transferred to the restaurant.
The challenge of this direction is to make such a system, which would, firstly, be convenient and cover all the needs of the operator, and, secondly, fast, because the client needs to be helped as soon as possible. In addition to the key task, the guys from Internal are working on reducing the processing time for one problem by the operator and reducing the number of calls.
R&D
When you need to change a business process and at the same time understand how these changes will affect the entire platform as a whole, Research & Development is involved. The guys conduct experiments, build models, count and weigh. They also interact most closely with the BI department, where they work with big data, ML-models, design neural networks, and forecast demand. In this connection, BI helps R&D with research and tools.
Research is mainly about working with data. For example, how the system will behave if you change some factor. Most of the tasks for R&D now come from logistics, as this area has the highest level of uncertainty.
Platform
This is a technical direction. First of all, the guys are aimed at improving the core of the system, refactoring order processing and decomposing our monolith. This is not a product development in the classical sense, but all the improvements are in one way or another aimed at making it more convenient and easier for users to interact with the Delivery Club application: reduce response time so that pages open faster, increase platform capacity so that more users can make order and at the same time the experience of use was as pleasant for them as possible.
Transformation results and new challenges
Our task was to build a development process that would meet all the requirements of a growing company: the teams are involved in the business, communicate a lot with each other, are responsible for the deadlines set by them themselves and understand how their work affects the end user. The process must be transparent, measurable and, most importantly, scalable.
After making a product transformation and optimizing the development process, we came to the conclusion that each of our releases became predictable. At first, we knew with an accuracy of 80% when and in what composition the releases would be released. Now, the average efficiency indicator for all teams within the department has grown to 90%. The involvement of the teams, that is, the motivation of the guys, has greatly increased, they understand what they are doing and why, to whom it is important.
The process includes the ability to respond to asap tasks without harming product development, there are enough communication points to flexibly estimate labor costs and respond in a timely manner to changes in requirements from the product manager. In practice, we made sure that the process is scalable: we managed to grow from 40 people to 170 with the same development process and without losing performance.
At the same time, we do not stop and believe that the product transformation is still ongoing. At the end of 2019, we began to think about how teams could influence business even more. The teams have a lot of product expertise, it seems that you can use it, come up with a kind of symbiosis of Technology and Business. In addition, we needed to come up with a mechanism for verifying product hypotheses. That is, to control the value of the tasks that fall into our development. To do this, we described the GIST process - a framework for verifying product hypotheses, which we will discuss in one of the following articles.
Thanks for reading!