Good article breaking down the limitations of the science driven approach to productivity that Accelerate presents, and some of it’s harder to prove claims.
I did find the capabilities and KPIs that Accelerate emphasizes useful, however. I agree with the author that there are a lot of other issues (such as building the wrong thing) that impact a businesses overall success. However if you’re on a team that’s focused on developer productivity, the four metrics offered (Deployment frequency, Lead time for Changes, Time to Restore Service, and Change Failure rate) are pretty good ones to focus on.
I also found surveys useful at identifying gaps in monitoring, detecting sources of toil among an engineering team, and gauging overall employee satisfaction, though they are not great at getting granular data. That said, they can provide good areas to dig in with more ethnographic research methods.
> Good article breaking down the limitations of the science driven approach to productivity that Accelerate presents, and some of it’s harder to prove claims.
I find this sentence really interesting, because it highlights that we seemingly don't read the conclusions of the text the same way.
Do you mean "science driven" to mean "inspired by science"?
Otherwise, my understanding of the post was essentially that neither "Accelerate" nor the "State of DevOps report" deserve to be called "science driven", as they lack basic control mechanisms one would expect from scientific works. And, I have to say, with some pretty convincing arguments.
…or did you mean that really scientific works on the matter are inherently limited because of the necessary rigor (which was also a take-away of this text for me)?
I suppose I should have put “science driven” in quotes.
But I also think it’s going to be difficult, using the methods available feasible for this kind of study, to draw strong causative conclusions about how dev ops practices impact business performance. There’s a lot of confounding variables that are hard to control for.
I did find the capabilities and KPIs that Accelerate emphasizes useful, however. I agree with the author that there are a lot of other issues (such as building the wrong thing) that impact a businesses overall success. However if you’re on a team that’s focused on developer productivity, the four metrics offered (Deployment frequency, Lead time for Changes, Time to Restore Service, and Change Failure rate) are pretty good ones to focus on.
I also found surveys useful at identifying gaps in monitoring, detecting sources of toil among an engineering team, and gauging overall employee satisfaction, though they are not great at getting granular data. That said, they can provide good areas to dig in with more ethnographic research methods.