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.
Let me start by introducing myself. My name is Alexandros, I’m a Golang (Go) Backend Engineer working on the Growth squad here at Delivery Hero. Over the course of my career, I have gained a significant amount of experience working on various agile teams. Today I’m going to share my Delivery Hero story with you.
Let me start by saying that every team has their own working style, depending on its squad members. For this reason, what I am about to share with you doesn’t necessarily represent how every team at Delivery hero operates.
PaySomeDebt Hackaton Day – A Hero always pays his technical debt
Technical debt is the result of prioritizing speedy delivery over perfect code. It’s like taking away a piece of your future productivity and happiness, to achieve something right now. One can only accumulate a certain amount of debt until working with the code gets tedious.
In my experience, all development teams are the same in this regard. Sometimes you have to move fast, as there is not enough time to do things properly. Other times it is just laziness..after all, we are only human!
Let me explain how my team tries to tackle the issue of technical debt.
PaySomeDebt Hackaton Day
Step 1: Visibility
The first step to solving a problem is by making it visible, so that’s what we do. We start by collecting all our technical, design or quality debt on post-its and put them on a board as TODOs.
A task has to be doable within a day or less. This makes them low hanging fruits, so to speak. We love low hanging fruits! We sort them by the impact it would have on our daily work if we get rid of them.
Step 2: Time
We invest a day and a half on each sprint to pay our technical debts. Then we pick from the tickets we collected in Step 1 and spend one day working on the problem and another half day wrapping things up.
It’s not perfect, but one of the better approaches I’ve seen so far. I think this is a great way to make technical debt visible to everybody. It also shows awareness of technical debt on the company/product side. After all – it may be correct that it’s the squad’s responsibility to keep the amount of debt at bay, but the product and ultimately the customer will suffer if we don’t get the time we need.
Bi-weekly Alignment meeting – In the Loop
An Alignment meeting is basically the place to show our overall progress, followed by mutual expectation management. Continuous alignment of expectations is what makes the Scrum framework so great. You don’t want to deliver a car when a Scooter is enough, or sometimes even a skateboard. And have you thought about the river we have to cross? You know what I mean.
There is nothing worse and more frustrating than finding out at the end of a Sprint or Quarter that you have been running in the wrong direction. In such a fast-paced, data-driven business like ours, we have to be able to correct our direction very fast.
“We’re not afraid to change. We are highly data-driven – and when data tell us to change direction, we will change direction” Christian v. Hardenberg (that’s our CTO)
I like the way we handle this alignment meeting, everybody in the squad is doing their part.
The process can be divided into four stages:
Step 1: Document your finished stories
Every finished task goes into the Sprints release notes. We call it “The Document”. My squad forgot to do this part once. As a consequence of that, we added a column called “Done” on the board, as a reminder that a task is only finished when it’s in “The Document”.
Step 2: Preparation – “Si vis pacem, para bellum”
This means, “prepare for war when you want peace”. That’s what we do in a nutshell. Since we own our product, we also have to be prepared for questions that may arise during this meeting. We create “The Document” in a way that answers most of the business questions, such as:
- KPIs
- User Interfaces
- Visibility for Backend tasks
- Tasks for an upcoming sprint
- Estimations
- Bug statistics
During this meeting, we also decide on who will be presenting at the alignment meeting.
Step 3: The Alignment meeting
As you can imagine, at this point everyone is very excited. Some of our stakeholders join us via Google Hangouts, while most of the team are in Berlin. The presentation is then shared on a big screen for everyone to see. If everything goes well, we manage to answer all the questions, receive valuable feedback and hey presto, everyone’s happy!
Step 4: Squad internal review after the meeting
After this meeting, we gather and reflect on the meeting. What went well, where we can improve and general feedback.
I think Delivery Hero must be the best-documented company/product I have ever worked for. You can basically follow all of our progress back for a long time. Everyone takes “The Document” very seriously. Our Squad’s Confluence pages are mostly up to date and very useful.
This is the second piece of my multi-part blog series on a developer’s perspective of Delivery Hero. Stay tuned for more content and if you’re interested in becoming part of the team, have a look at some of our open positions:
