In Part I of this series, I touched on the structure of our Standups, Retrospectives and explained the concept of a Sprint. In this part of the series, I will dive into detail on how heroes pay their technical debt. Much more importantly, I will share with you how we inform our stakeholders when we have failed to meet their expectations.

In my previous post, I touched on the subject of why DevOps for Data and Machine Learning applications is more difficult and costly to implement than on traditional applications. In short…
Wow, Data DevOps looks hard!
But don’t let this deter you. Making some progress is easier than you may think…

During our third quarter in 2018, I embarked on my journey of building a new cross-functional team for a greenfield project. Initially, when we first started, the team only consisted of a product manager and me, as the lead engineer. Fast forward a few months down the road and we had gained the support from two additional developers. The first engineer was working with us in our HQ in Berlin, while the second engineer was working remotely from South America, while his visa was being processed. At first, we didn’t really feel the need for having a specific process – we were using a Kanban board to prioritize and track progress on development. As the team continued to grow and our remote engineer relocated to our HQ in Berlin, we started having the feeling that we could be more productive. This is why we started testing scrum for our team. 

There are many ways that we impact customer experience. While traditional product and tech teams focus their work on creating a seamless ordering experience, working on our Automation and Support team means contributing to a positive customer experience after placing an order, especially when something goes wrong at some point in the ordering or delivery process. 

In the last year, our Restaurant Partner Solutions (RPS) vertical faced a massive cultural change when our containers orchestration migrated from ECS to EKS. Currently, YAML+terraform is the language spoken in our tribe. Before that, we used to speak JSON+cloudformation and it would take roughly one week to create a new service. Since our migration to EKS, we are able to create the service in a matter of hours and our developers are more empowered as we promote the “you build it, you run it” ethos.