Topics: DrDoctor tech
At DrDoctor we normally work in two-week Sprints. Every end-of-sprint (EoS) Friday we form cross-department working groups where everyone in the company gets to solve problems with colleagues they don’t normally work with. Nerds (that is actually what we call us developers at DrDoctor) like to use this time for quick “hacking” sessions to experiment with new technologies or try something new and ambitious that we have not done before.
Video consultations were something that our partner Trusts had asked about on several occasions. One rainy November EoS Friday we decided to spend a few hours on trying to develop a video meeting application and see just how far we could get with it. We thought this would give us some confidence when we decide to implement a video solution somewhere in the future. And let’s be honest, this is how us Nerds like to have fun!
As a first iteration on 15th November, we had some “very basic” expectations on what we wanted to achieve by the end of the working group (at least we thought they were basic, turns out they really were not). We divided these criteria into three categories:
Must
- As a staff member I can go to a webpage where I do a video appointment with a patient
- As a patient I can go to a webpage where I do a video appointment with a doctor
- As a patient the video works OK on my mobile
Should
- As a patient I am held in a lobby until the doctor arrives
- As a patient/doctor I can test that my camera & microphone setup is OK
Could
- As a staff member I can go to a webpage that lists my video appointments for the day
- As an awesome booking system, I can hit a scheduling API that 'books' the video appointments
- Very basic branding - colour and logo
We started with a well-designed diagram that was ambitious and very detailed, and of course, ended up achieving almost none of these goals...
(The well-designed diagram)
This was partly because we had zero prior experience with video calls but additionally, we tried to use Azure services, data storing technology and a web framework that we had not used before. One could say we were a little bit too ambitious. Nevertheless, we learnt a lot in just a two hour working group and were ready to try again two weeks later.
Two weeks later; on the 29th November naturally, our goal was to finish what we had started. By the end of the working group we had a working application where the user could see a list of appointments, join them, and have a video call with the clinician. Of course, we did not have a lobby, the users could not test their microphone or camera, we had no branding, we barely had any styling and during the demo one of the nerds’ video camera did not work.
Overall, I would say it was exactly what we expected from a demo after an EoS hack.
Forward to March
Once the COVID-19 pandemic threatened the NHS, DrDoctor reacted very quickly and changed the way we work. We switched to one-week Sprints, we put all non-essential work on hold, and we created new pods (dev teams) with new missions to react to the dire situation that the NHS had to face.
Our newly formed pod was responsible for developing a solution for video meetings as soon as possible, where “as soon as possible” meant one week for the minimum viable product (MVP).
10 weeks in the life of Video Service
From the beginning we designed our video service as a separate, standalone microservice which allowed us to use any technology that we wanted; we were not dependant on the existing codebase nor the existing infrastructure which made development much quicker. On the first week the focus was on developing and deploying an MVP to a UAT environment.
We were super excited (as you can see on the picture below) about what we achieved in less than a week with zero initial planning, we had a working solution with sophisticated UI elements and lots of extra functionality.
Ok maybe sophisticated is a bit of an overstatement, we did not really have UI elements nor extra functionality other than the video itself. Luckily, we still had a bit of time until the end of week which was enough to add a couple of buttons to mute/unmute the microphone, turn off/on the camera and end the meeting.
In the next couple of weeks, our partner Trusts started to test our video solution which gave us a great opportunity to listen to their feedback and shape our product accordingly. Having a small, focused team and one-week sprints, allows us to react to the feedback very quickly, however we needed to change our process to keep up with the pace.
Normally, at DrDoctor we work as a scrum team, we create user stories in our backlog, then we have a grooming session where we go through the implementation details so we can point the stories, finally at the beginning of each sprint we commit to a certain amount of stories (or points) that we will deliver.
However, in the current situation and with the current pace we simply didn’t have time to always go through all those steps, so we changed to a more Kanban approach. We still tried to groom and point the stories but when we more or less knew how to fix or quickly implement something, we just got on with it as soon as there was a nerd available rather than putting it in our backlog. We also stopped committing to stories and points, we usually committed to one feature or fix every week and did whatever else we could. This resulted in rapid development with a major feature and several fixes or UI tweaks every week.
As the Peter Parker principle says: “With great power comes great responsibility”. In our case this meant that with the insane pace came a good amount of tech debt. Luckily, our product owner is a nerd at heart, and he was more than happy to give us a week to look at those boring super interesting issues and fix them.
What did we learn?
Looking at where we started and what we achieved in only ten weeks makes me very proud and grateful that I can work with “such a great bunch of people”. This was definitely a team effort from everybody in the company including not just the product team but sales, transformation etc. Ten weeks ago, we started as a new pod and every week, we managed to deliver something significant. I think there are a couple of things that made us successful:
- Small but very focused team
Our pod was created with one main goal: Provide a solution for a video consultation to our clients as soon as possible. Having a single mission that everybody is focusing on in the team, made a huge difference. We did not get diverted to other areas (no context switch), we worked very closely together on every problem which made all of us experts of the product and we could make our own decisions.
- One-week sprints
First, this sounded crazy and to be honest sometimes it still does, but I think it had a big impact on delivering something meaningful every week. The fact that we have our end of sprint ceremonies every week which includes demos for the whole company made us want to deliver something cool every week. Sure, it increased the pressure on the team, but it also helped us prioritising our stories better, so we had something to show every Friday.
- Listen to your users
This is probably obvious, and I am sure most of the tech companies spend a lot of resources on user research, but sometimes it is only done in the design phase. We did not have time for that due to the situation, so instead we did it parallel with the implementation and pretty much we have been doing it since then. We reacted on the feedback straight away, sometimes it felt like our clients are designing our product, which is really awesome. This led to happy clients and great feedback scores which made the product team happy and confident.
- Process change
The final point is somewhat related to the previous one. We reacted very fast to the feedback, but we could not have done that without changing our way of working. We were able to adapt to the situation and change our development process rapidly because we were a small team with the autonomy to work any way we wanted. We did not even need to discuss if we want to change to Kanban, it just naturally happened. We stopped spending time with closing sprints or discussing what we want to commit to, and we just added the new stories to our current sprint. If any of us had to pick up a story which did not have enough details, we just tried to have a quick chat about it with at least another nerd from the team. (Ok we still had a backlog where we added tickets that did not have a high priority, but you get the point).
Where are we now?
We still work closely with our users, in-fact we have just finished implementing Video meetings which allows clinicians to create “adhoc” video meetings that are not linked to an appointment and the request for this feature directly came from one of our clients.
Next stop for our pod is DrDoctor’s new documents service. Another feature that was requested by our clients, which will be integrated with our existing products and it will allow patients and clinicians to upload images and documents and share it with each other.
No doubt that everything that we have learnt during the Video Service implementation will be useful to keep up the pace and deliver value to our clients in the future.