How to Measure Success for Development Teams

[@MichalMacierzynski73]

I'm looking for source of survey which you mention guys in some of movies ( it's done on 35000 samples in 2020 ). Can't find this movie anymore, can you advice ?

[@ContinuousDelivery]

I think that you are looking for the "State of DevOps" reports. It is more than one report, and confusingly, after 2018 there are two versions. The DORA, Google versions is IMO better for the recent ones, but don't ignore the older ones, there is some great stuff in the earlier reports: You can see the 2019 version here: services.google.com/fh/files/misc/state-of-devops-2019.pdf The best overview is in the book written by the authors of the report "Accelerate - The Science of Lean Software and DevOps".

[@MichalMacierzynski73]

@@ContinuousDelivery Thanks a lot, I'll go with this book as soon as I find any time for reading or listening. Keep up very good work with your channel, I've seen a lot of channels but this one is very good quality. I'm so delight seeing experts are saying things what I've been thinking already or finding out new answers for things I didn't know yet.

[@RobertMircea]

Can you point me to any concrete examples on how to measure defect rate and time to recover automatically?

[@ContinuousDelivery]

Some of this is covered in the "Measuring CD" book that I mentioned in the video. Defect rate is simple, as long as you take the rest of CD seriously and so have a good stance on automated testing. Within the pipeline measure test failures. Beyond the pipeline, measure defects reported from production - this is second best for an overall picture, but you need this metric to really evaluate the quality that matters, that perceived by your users. TTR is measured in the pipeline as the gap between a test failure and all tests passing again. TTR in prod is a bit more difficult to automate. But you can correlate commits, and so releases, with Bug IDs.

[@peanarchist]

Your videos are very informative, but I really want to bin your microphone. The room sounds like you're ordering mcfries from Uranus.

[@ContinuousDelivery]

Yeah, I've learned a lot since I started the channel, and I hope you will find that the sound quality is much better in my latest videos.

Enlighting.

[@ContinuousDelivery]

Thank you!

[@JonathanCrossland]

Incorrectly and sadly this sweeps all context under the carpet and concludes that all software teams have success when doing all of these things.. The problem is, not all teams, products and code are the same. Not all code operates at the speed of Google and Amazon. Not all software is public open products, but inhouse or products for a limited and consistent client base. Products with a known value. Such systems won't need to test out ideas, or update 10 times per day or worry about lead time. When you say that you can measure and then use metrics that not all teams use, it's kind of a dud metric. How many out there are incorrectly trying to apply these ideas to their contexts? Good ideas in the wrong context are bad ideas.