Topics: Agility at Dr Doctor
My experience of joining the DrDoctor Engineering Team and how it continually challenges itself to think differently and challenge its Agile processes.
I joined DrDoctor in September 2022. Stepping into my new career as an Engineering manager at DrDoctor was a world of unknowns. I had previously had a long career as a Pharmacy Manager and my last role was an Operations Manager in a fleet maintenance company. This is my first role working in a tech industry and although I had great skills of people management and leadership to fall back on, there has been so much to adapt to working in a new role in an industry that was completely alien to me 3 months prior. I was excited at the prospect of playing a game that would help to broaden my understanding of not only working in an agile environment but also learning more about a product team.
In January, we had the opportunity to invite Emma Hopkinson Spark, (the creator of the game and Chief of Staff at 101 ways), into our office to facilitate a game of Agile 101. I had little knowledge about the game before the day; I’d had a few catch ups with Emma, but all I had seen was the information on their website. I knew that it was an original card and dice roleplaying game in the style of Dungeon and Dragons, and that the aim of the game is to get your app to market, gaining as many users as possible on the way. Having never played Dungeons and Dragons and being new to product, I had no clue what to expect. Emma explained that all that was required was a space large enough for us to play the game and that she would bring the cards.
Around 30 DrDoctor employees attended the games, predominantly from product, but also a few transformation and people team colleagues. The group was split into 4 teams at random, where some teams were a complete mix, and others were roughly based on a pod with some additions. We were given a short introduction then got stuck straight in.
All we needed to do to get started was choose a role to play. There was 1 Product Manager, 1 Delivery Manger and the rest of the team were developers with varying skillsets which enhanced the score when the dice was rolled. Lots of the people playing opted to play a role different from their day-to-day at DrDoctor. The aim of the game was to develop an app for sharing funny cat videos and get the most users.
The next part of the game was the ‘sprint’. The cards we had were feature cards which had developer points (the developer has to role the dice to reach this score or higher), equal to stories in the backlog. We had to plan the features we wanted to bring into sprint as a team, with the aim of successfully releasing something by the end of the first round. Once all MVP features were released, we could start the race to gain the most followers. The ‘Developers’ then rolled the dice to see if they could hit the points for each feature. ‘Developers’ could work independently or pair up to release a feature. If you hit the number or higher, you've developed your feature. If you don’t, it can still be released but you incur a ‘bug count’, or it gets rolled over into the following round. There was also a curve ball of an event card that could either increase or decrease followers depending on the outcome. At the end of the round an event card is drawn which can impact the release. The Delivery Manager then has to role the sum of the cards to enable a successful release. At the end of each round you needed to record the score and like a retrospective at the end of a sprint, review tactic. You also must plan effectively and learn from the last round.
After a couple of rounds everyone grasped the game and was really into it. Looking around the room the atmosphere was electric. There was laughter, joy, and frustration. Lots of debate and decision making. It was great to see everybody getting involved, having a part to play in the team and rooting on the team to succeed. Tom G blurted out ‘This is F**king exhilarating!’ after rolling a 20 and automatically getting 10,000 extra users. After a huge groan in the corner, Ken had his head in his hands; the event card meant they had just lost a substantial number of users. In little to no time, the teams were deeply invested in getting the most users for their cat app. We played 6 rounds in total and as the game was nearing an end and the pressure mounting, Emma threw in another few wild card scenarios that could benefit or detract from the final number of users.
Once everyone had completed their rounds, we totalled up the scores, regrouped and had a reflection session on what we had learned and what the biggest takeaways were.
These were:
- Inclusive for all - You can play this game if you have no clue about tech and engineering teams, or you could have worked in the industry for years and still come away learning a lot. The game enables everyone to play and for beginners or people outside of product, it really gives an insight into the reality of what a day in the life of a product team is like. Beth H said "As someone participating who isn't in a technical role, Agile Games really helped me understand how Engineering teams work and the various spanners that can be thrown in the works. Really fun and enjoyable session that I'd do again!"
- Prioritising the Backlog - Some teams did this well however; my team had all of the feature cards all out on the table. This made it hard to identify what to bring into the next sprint. Whilst frantically scanning the cards, the team didn’t fully read all the cards and focused on getting small deliverable features out. What we missed was that there were cards like the CI/CD pipeline which enabled features to be released early and gain more users at an increased pace. Prioritising the cards enabled teams to think strategically when planning what was brought into each sprint. It also enabled the teams not to be driven only by the product, but incorporate the infrastructure.
- Communication in a team - It was important to work effectively and efficiently in small teams to complete the round. Communicating clearly and listening well to other team members was key. Debating with colleagues was a given, but we needed to be decisive and quick with our decisions so as not to impact the time we had to play.
- Delivering Value - It wasn’t just about getting feature after feature out the door. Careful thought and consideration had to go into each round to ensure we were delivering what the users needed. This could mean pairing up and focusing on getting a larger feature completed, which could then have an influence on the number of users.
- Sprint Planning - Not to bring too much into the sprint that could impact the release. To keep the focus on delivering value, bring small achievable features into each sprint.
- Tech Debt – Accruing tech debt meant a deduction of points at the end of the game. This had to be focused on regularly to stop it creeping up and having a huge impact on the number of users at the end of the game.
At the end of the session everyone agreed there was a lot to have learnt from playing the game and they had great fun doing so. It really helped to re-evaluate the agile approach we have at DrDoctor. It helped to validate and identify what we are doing well and how we can look to improve the day-to-day running of the teams, to ensure we are putting our learnings into practise. Like pairing up more to get tickets through more efficiently and ensuring we have prioritised the work to ensure what we are working on is the right thing from the research with the clients and that we are delivering value.
For me personally, it was incredibly useful and insightful on how a product team works together and the challenges that can face developers each sprint. It gave me an insight on how my role works within the team and how I can help to share back my observations that can enable the team to see things they might not have if they are stuck into developing. I was lucky enough to have the PMs I work closest to, Alasdair, Steph and Owen, and a new team member, Gareth in my team. It was nice to collaborate with them and understand their way of thinking. I found it useful to visualise the sprint with the cards and understand the flow. It helped me understand that the PMs are always being thrown curveballs that must be prioritized and that can take away from delivering value. For example, client requests or tenders that require features that are not on our road map. Also, that we need to utilise the retro to focus on making improvements each sprint, and that pairing and collaborating more is a huge benefit to the team and can help to improve the next sprint.
It was great to see early in my career how important it is at DrDoctor to challenge the status quo and think of different unique approaches to help nurture a culture of teamwork, collaboration, innovation and continuous improvement. This wasn't only a memorable experience, it sets to tone for each and every employee to bring new ideas to the table and work collaboratively and cross functionally in future.
We were fortunate enough after the success of the session to be donated two packs of cards by Emma. These now live in the office and can be used on team collaboration days to look at ways to work better as a team. Identify the strengths that we have and create a space to really innovate in a safe environment to try something new.
You can find out more about The Agile games on their website: Agile 101 | The Agile Development Game | 101 Ways