Abstract (delivered by video on an exceptional basis):Dodo Pizza IT team grew from 2 developers serving one country to 60 people serving 11 countries over the course of 7 years. I rebuilt our processes and implemented some engineering practices, but this was too slow. It was not clear how to organize the quality work of several teams on a single product.
We are too carried away with the development of business features and have accumulated too much architectural technical debt. When marketing launched an advertising campaign in 2018, we couldn’t stand the load and fell down. It was a shame. But during the crisis, working in an extreme mode, we realized that we can work many times more efficiently. The crisis has pushed us towards revolutionary changes in processes and the rapid introduction of best-known engineering practices.
After the crisis, we took the LeSS framework as a basis and imposed a number of engineering practices on it. Some of them worked perfectly, while others did not. For example:
- Try: Feature-teams
During the crisis, we worked in teams that made a feature from start to finish and were not dependent on anyone. It was great. After that, most of our teams are cross-functional and cross-component feature-teams. - Avoid: Unstable teams
During the crisis, the composition of the team was chosen for a specific task. But we quickly realized that it was much more comfortable for developers to work in stable teams. - Try: Stop the line
The more changes you make between releases, the more risky each release is. We stop development if the release takes more than 48 hours and focus on eliminating the causes of the delay. Over several stops, we significantly stabilized and accelerated the deployment pipeline. - Avoid: Bug fixing team
Previously, we had a separate team for bug fixing. Now, after introducing the practice of Zero bugs policy, this team become redundant.
We have built an efficient process in which 9 feature teams work on a single product in a common code. We learned how to combine business development and gradually improve the quality of code and tests. We split the monolith into microservices and use the DDD approach. Our process has not yet been settled, so we continue to experiment with engineering and process practices. But we firmly know that the focus on technical excellence is a guarantee of the stable development of our business.
Lessons Learned from Your Experience:- Engineering practices protect business from crisis
- Do not accumulate technical debt. It may be too late and cost too high.
- Evolutionary changes take several times longer than revolutionary ones.
- Crisis is not always a bad thing. Use crisis to revolutionize processes.
- However, a long evolutionary preparation is required in advance.
- Do not blindly implement all the practices that you like. Some practices are waiting in the wings, and when he comes, the teams will use them without resistance. Wait for the right moment.
- Over time, the teams themselves begin to make strong decisions and implement them.
