Having experienced various forms of agility – ranging from companies who only use Scrum ceremonies as a reporting mechanism, to companies who actually live the agile mindset, get the philosophy behind it and have a shippable product after every iteration and everything in between – I have to say that Delivery Hero understands the agile mindset.
Let me introduce myself – my name is Alexandros, I’m a Golang (Go) Backend Engineer working in the Growth squad here at Delivery Hero. Over the course of my career, I have gained a significant amount of experience working in various agile teams and 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 the squad members, so what I am about to share with you doesn’t necessarily represent how every team at Delivery hero operates.
Always sprinting!
According to Scrum.org, the term “sprint” comes from Scrum, it’s basically a “time frame of one month or less during which a “done”, usable, and potentially releasable product increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.”
A sprint always starts with a “planning session” and ends with a “retrospective”.Our sprints always result in a shippable product and create business value. Always. You can’t call yourself agile if you don’t meet those criteria.
The “Why” aka product/customer view is always the center focus of every ticket and discussion we have. We are continuously self-reflecting on each new iteration and trying to improve ourselves and our process.
Of course, not everyone agrees on everything, but we all commit to finishing the sprint and making our product better (Amazon-style). I strongly believe that the agile mindset has to not only be lived by each team member, but also by management and beyond. At the end of the day, we are all here because we want to reach one common goal – and that is to satisfy the customer.
Let’s begin by breaking down the sprint process:
Standup
A Standup in Scrum is basically a short (~ 15 minutes) alignment meeting that we have every day while standing in front of our whiteboard. The purpose is to keep ourselves updated and focused on everything sprint related, with the main goal being to discuss and remove obstacles.
I noticed that there are a few things that we do differently during our Standups here at Delivery Hero:
Conductor
The first unusual thing that I have never experienced before, was that we have a conductor for all of our Standups. The basic idea is that every team member is leading the team throughout the Standup by:
1. Pointing to the board item
2. Reading the title/description out loud
3. Actively asking the team about its status and if any blockers are in the way and how to go about solving it as a team.
4. Writing down any daily action required to unblock those items.
I think this is a really cool and refreshing idea that helps us stay focused and starts the day in an exciting and positive way. Not to mention the sensation that you get when the ticket that you’ve have been ever so diligently working on moves over to “Done”, of course, followed by applause from your teammates. This will make your day, believe me. I love it.
If you are interested in reading more about how to spice up your Standup by adding the Conductor’s role, check out the article that we posted a few weeks ago here.
Everything analog
The second unusual thing I noticed is that on top of having a physical and digital board – all tasks are handwritten by a team member at the start of each sprint from the digital board (Jira) into Post-its, which we then stick onto a whiteboard. Previously, I have only been used to working with digital boards with touch screens during my development years, where we directly move the tickets in JIRA.
That seems to me like a huge overhead! I remember asking our Scrum-Master, Ivan when I joined Delivery Hero if he knew that we could just print all tickets. He told me, it was mostly because of the psychological effect it has – we tend to give the tickets more value when they’re handwritten and we can better identify with the tasks.
Although I have mixed feelings on this, especially about the fact that we have to keep two boards updated and those post-its constantly falling off, I think it makes sense and adds a personal touch to each ticket.
Board layout
The third unusual, yet interesting thing, is the board layout.
A sprint is successfully finished, when tasks have been moved from “pick me” to “done”, nothing new here, I think the lanes are self-explanatory.
What I found interesting, are the side lanes:
Sprint Improvements: Every sprint, the conductor asks us about the action points we agreed upon in our Retrospective and goes through each one of them. That’s an effective way of reminding everybody about our action points. In my previous experiences, the team always forgot about these items during the sprint, now it’s a concise decision, that we all discuss.
Previous Improvements: Reminds us of all the successfully implemented improvements.
Daily Actions: Are actions we have to take in order to resolve an issue that is currently blocking somebody or something.
Conductor: A list of all team members that are taking turns conducting the Standup, having a different team member each standup.
Retrospective
One of the essentials of the agile mindset is self-improvement and continuous learning from the whole team. The retrospective meeting is the place to express your constructive feedback and identify how the squad and each member of the squad can improve the process, product and approach in the next sprint.
Some of the questions we try to tackle are:
How we can help each other? How we can achieve more? How we can have more fun working together? It is also the place to talk about all the good things that we experienced and celebrate our successes.
I found the retrospective to be shorter here at Delivery Hero than in my previous companies, but nonetheless effective. Our team mostly uses the timeline format, where we place all the things that happened during a sprint and once everything has been mapped out, we cluster them into relevant segments.
Goal: Share what was great in the previous sprint and what we enjoyed. Create an action plan on what we should do differently in the next sprint and going forward. What will help us to work in a more productive and comfortable way?
In conclusion, I’ve really enjoyed the way we work here at Delivery Hero. It’s fun, engaging and the team is laser focused to deliver solutions for our customers. Because at the end of the day, that’s the reason we are all here.
This is the beginning of my multi-part blog series on a developers 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:
