Exploring DORA

We are considering implementing DORA metrics to help track and improve our outcomes. I had never heard of the term DORA, but most of the metrics rolled into this moniker I have a history with. As part of the discussion around DORA, we met with a few vendors whose products integrate with GitHub, Jira, etc., to surface metrics. While we didn't end up purchasing a product to help here, it wasn't because we needed to see the value of DORA. On the contrary, we value the outcomes that DORA metrics (et al.) are after; it is more about timing. Through acquisitions, mergers, and growth, we have a diverse group of teams, each at different maturity levels and mechanisms around SDLC. Starting to track DORA-esque metrics when a team may be working to climb up on the maturity curve seems premature for a few reasons. First, we should focus on helping teams up-level their SDLC. For instance, CI/CD is good, so everyone should do that. Second, most mechanisms have some metrics as outputs that we can leverage. If you're doing Scrum, are you tracking the key metrics or meeting every two weeks to plan work? Lastly, we need to be careful when comparing across teams that don't do the same thing or have similar needs. The apples and oranges analogy exists because it works.

As a team leader looking to uplevel the entire engineering organization, DORA and products that capture related metrics sound attractive from a centralized visibility perspective. Being new to the organization, I know relatively little about each team's maturity level, but many feel there is room to improve. Does that mean we are not going to track any DORA metrics? Of course not; we will track the ones with shared mechanisms and leverage that data. Measure, identify, improve, repeat.

P.S. I was pre-Dora The Explorer. But my kids weren't. Geography interests me, so this Dora is fabulous in my book.