Hello! I am Katya, a Project Manager at IMAGA. In 2020, I started working with a small team that was developing a mobile app for a large online clothing store. I found the project challenging and interesting at the same time.
On the one hand, the customer said right away that there are plans to create a hybrid team, in which our people and the customer's employees would work as equals. The task was to set up processes for the part of the team where I was a contractor.
On the other hand, there was an uncontrollable flow of tasks with no priorities. Tasks came pouring in from anywhere, not all and not always were evaluated, there was no release plan, etc. Therefore, technical debt and defects accumulated, and business tasks were out of production for several months.
In this article, I'll break down these problems and tell you how we fixed the situation.
Why it was difficult
When I joined the project, the team had just finished an MVP release and moved to a new work model. The company tried to implement Scrum, but everything worked chaotically and depended on random decisions. For example, a feature could get into the current sprint, before other tasks were removed. This affected both the timing and quality of the work. There was no culture of running the board, no record of the team's workload, and technical debt and the number of defects were growing.
But I got lucky. The customer was aware of these problems and wanted to solve them. A methodologist was brought in to help the team build a unified work process. Our mutual goal was to implement a Kanban system and rearrange processes to make the entire team comfortable. The tricky part was that we had to implement all the practices in the already existing team, which was used to working without a system.
By that time, a lot of blockers had already accumulated, which determined the behavior of the team and the customer. The new format of work was not easy for anyone, so we had to justify all the changes. Over time, as the team began to grow, this became easier — newcomers didn't know how it worked before and worked by the established rules.
First of all, we identified three big, interrelated problems. We started to solve them together with the methodologist and the team.
Problem No. 1: Tasks were taking too long
In the beginning, one sprint could last a month and a half or two months. The life cycle of one task was too long. This had a significant impact on all processes, and ultimately on the quality of the product. The reason was that the team did not understand how crucial different defects and tasks were. At that time, the rule was «All bugs are important, and all tasks are urgent.»
It was a wrong approach. We were accumulating technical debt, and the backlog was a mess. The developers tried to do everything at once. This system made it difficult or nearly impossible to predict results and deadlines.
What we did
The first thing was to set up versioning. From that point on, the set of tasks of a sprint was determined by planning. We decided in advance what features we would develop and what defects we would fix within a sprint. In doing so, we made sure that there couldn’t be more tasks planned for a sprint than we can do.
We made it a rule to keep the board in Jira up to date. We set WIP limits: 2 tasks in development, 1 in review, and 1 in performance testing. It is better to make changes to the product gradually but regularly rather than to have a large number of chaotic changes.
Each task now had to go through all the stages so that we could control the load, find bottlenecks, and redistribute functions promptly. For example, if we realized that there was a problem with testing, a developer would get involved.
Even more important goal was to convince the business customer that these changes are necessary. It took a lot of time and effort to explain why a sprint should not be overloaded with new features. We explained it during our meetings and calls. Based on the results of the meetings, we prepared a rally report, a key element of communication. After each meeting, all participants received a letter detailing the decisions made. If there were further questions or conflicts, we had something to refer to.
We chose tasks together with our business customer. When planning a sprint, we introduced an Epic system.We placed it on a separate Kanban board, prioritized by position in the column. It helped us not to slow down important business processes while keeping an eye on both the quality of the product and the process. Before that, we determined that in each sprint we take no more than 20% of tasks concerning technical debt and defects. The rest are business tasks.
We also made a table of sprints and fixed it in the Confluence space.There, we kept track of when the task was received and when it would be implemented (i.e., the planned release date).
We gave up the idea that the contractor had to finalize all the assigned tasks. For example, a developer was working on a 40-hour task, and the previous task got reworked. The developer will not have time to begin the task revision in this sprint. So, we pass it to another performer — whoever is free, that person gets the priority task on the list. This reduced development time at the sprint scale and increased the team's involvement in the project. Every performer knew about every task.
Tools: Kanban boards in Jira, Epic system, rally reports, scheduling meetings, WIP limits, sprint fill rate table in Confluence, specialist interchangeability, sprint task percentage, versioning tags.
The results
All this made the work process smooth and more transparent. The sprint period was shortened to 2.5 weeks, and the efficiency increased. We started to sort out the backlog and technical debt faster, and project metrics improved.
Problem No. 2: The team was on the edge of burnout
Working under constant time pressure causes great stress for any team. One of my goals was to keep people as well as recruit new developers to strengthen the team. So, we had to quickly figure out how to make work comfortable for everyone and raise the team spirit.
Once again, systematizing the process helped. As the sprints became shorter and the amount of work being done became clearer, this problem was partially solved. But this was not enough, it was crucial to build trust in the distributed hybrid team.
What we did
We made retrospectives mandatory. At these meetings, we discussed each sprint in detail, outlined problems, and looked for solutions. Retrospectives used to be done as a residual — «if we have time, we’ll have it.» However, there was never time. We managed to convince the team, including the client, that retrospectives are important not only for the team but also for the product as they allow us to avoid repeating mistakes and grow as a team.
Retrospectives were held at Miro. Every time, a meeting was led by a different team member. We wanted people to have more influence on the process and to dive deeper into the project. We quickly extended this practice to daily sprints as well. When everyone knows their teammates’ tasks, they are more responsible for their own ones, it's motivating. The basic idea: everyone participates in the process, gets immersed in the tasks, and sees the project as a whole.
Distribution of responsibility within the team has become a basic tenet of our work. The idea that everyone should be equally responsible for the final product made the process smoother. At the same time, it helped to reduce the number of bottlenecks. Let me give you an example: now each team member could, to the best of their ability, take on the responsibilities of the others. Interchangeability made the process more productive. As a bonus, everyone got to see their growth.
I made peer-to-peer feedback mandatory. Every 2–3 weeks, I conducted surveys to see how people felt in the team. It included calls, Google forms questionnaires. Sometimes I talked to our supervisors, team leaders, and the customer's supervisors. The goal was the same — to understand the needs of the team and create a comfortable atmosphere.
Tools: Miro retrospectives, Google Forms surveys, One-on-one meetings, team interchangeability, daily sprints, and retrospective with different leads.
The results
We managed to stabilize the team, the team members began to think positively. We reduced stress through changes in processes, we got rid of time pressure and overwork. As a result, the team almost tripled in size. At the start, there were five or seven of us, but now there are more than 15.
Problem No. 3: The team was pressured all the time
The attitude of the business customer also had an impact on the team's burnout: problems were often resolved through conflicts. Communication was tense and stilted. There was no mutual understanding. It was important to find common ground.
What we did
After we set up versioning and explained to everyone the principles of sprint planning, it became easier to work. But to get rid of the problem completely and make the relationship work, we introduced the three-legged rule. Once every month or two, we met with the head of the client’s company and my management team. We discussed the ups and downs. Everyone received useful feedback.
Along the way, we found out that the main problem was inability to predict the exact deadlines for tasks. This alarmed the top managers and made them want to rush the team, which had no time to deal with the technical debt and defects. Instead, we had to make new features that got into the sprint outside of planning.
To avoid this, we started holding backlog replenishment meetings with customer executives. At first, we held them once in a sprint, but it wasn't enough. So, now they take place at the beginning of each week. At these meetings, we use planning poker, a methodology for evaluating tasks. Now it's easier to reach agreements on the amount of work we take in sprints.
Daily sprint meetings also take place with business customers. It was important for us to convey to both the team and the top managers that daily meetings are not about finger-pointing, it is a way to update the status of tasks and their timing. If there are issues that need discussing, we either have a separate meeting to deal with them or discuss them at the end of the day.
Tools: Three-legged rule, backlog replenishment meetings with the business customer, planning poker, daily sprints.
The results
All these measures took the edge off the tension. The team is more comfortable and the customer is more relaxed. Relationships were not only stabilized, but also greatly improved. Now we are planning new projects with the same customer. It's a good sign, as it means it wasn't all for nothing. Plus, there is less turnover on the team, and the established system helps specialists to grow.
What we achieved
My personal goal lay not just in building processes but in making them convenient for everyone. All the changes described in the article were met with some resistance from the team. The resistance reached its peak when it became a full-fledged hybrid team and I had to manage my colleagues from IMAGA and the customer's staff at the same time.
Some people didn't want to lead the retrospectives and the daily meetings. Team members sometimes forgot about the board culture. But in the end, my team and I have been able to change the situation and build a system where everyone is responsible for the product. This influenced the metrics and the relationship between the team and top management. We achieved high Crash-Free user rates of 99.8–99.9% on iOS and Android by reducing
At the start, there were five people on the team, but now there are more than 15. The sprint, which originally could last a month and a half, now lasts 2.5 weeks. Any conflict situation is resolved by an open and constructive dialog. What's even more important is that new features get to users much faster.
