Handling bugs at Doctolib

Doctolib is a service that can be split in two different products, a B2B software and a B2C platform.

Our first product is a medical scheduling software heavily used everyday by more than twenty thousand active healthcare professionals and their assistants. If a feature is broken, they may simply be prevented from doing their work properly.

Clients can reach our support team which is handling around 500+ contacts per day (coming in by phone, email or in-app ticket or chat) and bug reports represent 3% to 5%.

Our second product is an online booking platform for patients (several million online bookings per month). We have a dedicated support team to help patients throughout their booking process.

Despite our strong focus on software quality (6 thousands automated tests, end-to-end tests in a real browser, systematic code reviews),we cannot entirely avoid bugs slipping to production :(

As a remediation, we have setup two simple rituals a year ago that have proven great results and we’d like to share.

5 minute daily meetings between the product team and the support team

Gil, member of the support team, visits daily our 5 product owners for a few minutes in order to have an update on any important running issue.

This daily meeting ensures that the product team is aware of what the support team has to cope with in terms of contacts.

Tickets are fine to describe how to reproduce a bug, but it is not an easy way to share the level of dissatisfaction associated to it (how to keep updated the number of impacted users for example). Thanks to this discussion, the support team and the product team agree more easily on priorities.

Critical bugs are fixed right away by the engineering team. But for the most part, all other bugs go through another ritual.

Monday is Bug day

Every Monday, all engineers focus on fixing as many bugs as possible.

As much as they can, the support team tries to make it reproducible to help the engineering team. If they can’t, the product team gives it a shot. If they can’t either, the engineering team will try during the bug day (and if one engineer can’t, another engineer is involved, etc).

Bugs are prioritized by the product owner and the backlog is shared with the support team. At the same time, a few engineers fix issues reported by Sentry, the error tracking software in use at Doctolib.

Reasons we work like that

Having a clear ritual makes it easier to stick with it.

1. Using a one day time box allows us to control easily the time spent on bug fixing so it will not affect time for feature development.

2. Having a weekly recurring event ensures it will not be skipped. Our roadmaps are ambitious and we want to deliver the best product, which needs a great focus. As a result, bugs can easily be discarded with “we’ll fix this once we’re finished” and never be rescheduled for resolution.

3. Fixing and investigating bugs can be a hard and ungrateful task. Having everybody at the same time working on them helps focusing the team. If an engineer needs help, he knows everybody has the same goal and will not hesitate long before asking for help.

4. The support team can give quick and better feedbacks to customers reporting an issue. They know that small bugs won’t be fixed in ship in production within 10 minutes… we need the engineering team to stay focused as much as possible. But they also know that on Monday, there will be a batch of fixes and they can anticipate that in their communication to the client; “I will come back to you on Tuesday, is that okay for you?”.

5. We can tackle little bugs that would never find any space otherwise. Thankfully, we fix more bugs than we add, so we can fix minor bugs to target a 100% satisfaction from our customers.

We think it is not relevant to follow as a KPI the exact number of closed bugs by engineers but we strongly follow the satisfaction level of our clients regarding the quality of our software.

The very close relationship between the support and product teams is our best way to let us all know how good is the product we deliver.

This workflow is not perfect, and there are opened questions:

• How to handle bug that need more than one day to be fixed? Regarding bug criticality, either we finish the correction next day and impact the team delivery, either we shamefully finish the fix one week later.
• One day per week represent 20% of an engineer job time. It is a very big investment we would obviously like to reduce. By how much can we decrease this ratio without impacting significantly global satisfaction?

We are starting new experiments to answer those questions and maximize the efficiency of our teams. We will keep you posted in a few months if they are successful!

PS: we’re doubling the size of our engineering team in Paris, find out more!