The Dora Retro

The Dora Retro

Book retros

I like to do retros often, to have short feedback loops, and with variety, to stimulate conversations and topic diversity. Given that context, I have debility for what I call book retros. A book retrospective is a thematic retrospective built around the main ideas explained in a book.

The goal of a book retro is multiple:

  • Gather ideas on how to improve (as usual with retros) on a topic (maybe the topic is not your usual topic though)
  • Very short training around the topic (hopefully to trigger team’s interest on the topic or at least raise awareness)
  • Align team expectations on the topic
  • Bonus point: Help getting your retros out of the groundhog day if you have such problem

The Accelerate Dora retro

One of the books that had bigger impact on me the most during these last years has been Accelerate, by Nicole Forsgren Phd, Jez Humble, Gene Kim, so I decided to prepare a book retro of it. Circumstantially, the Accelerate retro became the Dora retro, as a lot of the content was in the end extracted from the Dora research program :).

How to use it:

  • You can download the retro material from here. This post explains the motivations and rationale behind the retro and its activities, is meant for the facilitator. The material is meant to be shown to all participants during the session.
  • The retro focuses mostly on technical aspects of Software Development, so in our case we did it while our PM was on holidays
  • The exercise doesn’t necessarily need to be done as a retro. You can do it anytime and you can set it up to gather experiments for the next week or goals for the next quarter, up to you.
  • As somebody already noticed, it may remind you of the spotify squad health check model, which they suggest to do on a quarterly basis, that could be an option too. I was not aware of such model when I created the retro, but thanks anyway to Henrik Kniberg and Kristian Lindwall, I shamelessly have borrowed part of your model to improve the second exercise ;).

Ice breaker + Prime directive

I always start my retros with an Ice breaker because I want people to clean their slates when entering a retro. Ice-breakers help people disconnect with what they were doing 5 minutes before entering the retro and that's very valuable as it usually lightens the mood and allows for better perspective during the exercise.

After the ice breaker and before getting our hands dirty we read the prime directive, it never hurts.

Feel free to skip both steps.

What is Dora?

Dora is a company that was founded by the authors of Accelerate (and also authors or coauthors of "Continuous Delivery", "Lean Enterprise", "The DevOps Handbook", "The Unicorn Project" and "The Phoenix Project" - they are all excellent reads). Dora focuses on DevOps and helps companies improve their organizational performance (including Google, I guess, as they acquired at the end of 2018).

I think it’s worth reflecting on the fact that you could understand DevOps as a way to improve collaboration between Dev and Ops, but we should not forget that the whole motivation behind improving their collaboration is because that improves organizational performance (what we are really looking for and what DevOps is implicitly becoming the term for).

Dora annually publishes the State of DevOps report, which gathers data from companies all-over the world. These reports are the outcome of their rigorous research on practices and capabilities of high performing tech orgs.

Retro goal

Reflect on their findings to see how we could improve.

Performance key metrics

The Dora research uses 4 key metrics to differentiate low, medium, high and elite performers. The 4 metrics are:
  • Deployment frequency - How often does the organization deploy to production
  • Lead time for changes - Time from code committed to production
  • Time to restore service - When an incident happens, time to restore service
  • Change failure rate - How often changes degrade service

While introducing this concept it’s nice to justify WHY those 4 metrics were chosen (See chapter 2 of Accelerate for more info) and also to highlight their relationship with SW Development, SW Deployment and Service Operation.

Activity I

  • Self-assessment (5 min) - For each of those metrics, ask every team member to vote at which level do they think the team is now. This should be done hidden and in parallel, to avoid anchoring.
  • Discussion (10-15 min) - For each key metric, reveal the votes and discuss the motivations behind them.
  • Think time (5 min) - Give every team member 5 minutes to think about experiments to improve based on whatever inspiration they have after the discussion. Experiments should be kept hidden until the next step.
  • Pick one experiment (10-15 min)- And only one!

Predictive relationships

The studies from Dora have found a series of relationships between capabilities and outcomes. Those relationships are positive predictive meaning that the existence or practice of the element on the origin has a positive impact on the destination element. The best way to explain this is by opening Dora's animated diagram and playing around.

Given the diagram I’d like to share these insights:

  • Organizational performance (probably the most interesting bubble for your organization) only has 3 predictors: “Lean product development”, “Culture and work environment” and “Software delivery & operational performance”. So, if you want to improve your organization, that’s where you should put your efforts.
  • You are now in a retro, good for you because you are investing in “Culture and work environment” which as you already know impacts organizational performance :)
  • Continuous Delivery looks like an interesting topic (one arrow in, five arrows out, pretty good ratio!). Only by working on “Technical practices” you will have a positive impact on “Culture and work environment”, “SW delivery & org. perf.” (note the importance of these two dues to the previous statement), “Less burnout”, “Less deployment pain” and “Less rework”. Who wouldn’t want to improve on all those things?

So… since this is a technical retro and improving on Continuous Delivery will have such an awesome impact, let’s take a look at Continuous Delivery technical practices.

Activity II

  • Describe the practices (10 min) - Continuous Delivery is composed of 12 technical practices, explain them to the team so everyone understands what they will have to assess
  • Self-assessment (5 min) - For each of those practices, ask every team member to vote at which level do they think the team is now. This should be done with hidden votes again. Feel free to use the table underneath
  • Discussion (10-15 min) - For each technical practice, reveal the votes and discuss the motivations behind them
  • Think time (5 min) - Give every team member 5 minutes to think about experiments to improve based on whatever inspiration they have after the discussion. Experiments should be kept hidden again until picking time
  • Pick one experiment (10-15 min) - And only one!

Fist of five + Feedback

So, you should have now 2 experiments for your next sprint, one inspired by the 4 key metrics and the other by the CD technical practices. It's time to take 2 minutes to reflect on the retro. I like to do a fist of five and ask for feedback on how to improve in the future.

Specifically for this type retro, I also like to have a small conversation on:

  • Have you learnt anything new?
  • Any special interest in one of the topics discussed?
  • Has the shared understanding of the team improved?

And that’s all, thanks for the patience and have a nice day :),

Xavi

Credits: Thanks José Carlos Gil, Aitor Alzola for reviewing and feedback.