The Agility Series — 4 — Success Metrics
If you read Accelerate: Building and Scaling High Performing Technology Organizations, when it first was published (Forsgren et al., 2018) then you probably got a bit excited. My honesty must reveal that I was skeptical. I read it and was relieved that DevOps finally had a manual — in a sense. I was in DevOps at the time. But, it confirmed my skepticism. Martin Fowler in the forward makes mention of the reality that this book is focused on what happens after you commit code. Not really while you are laying down lines and especially not before you get to your keyboard if you are a coder.
In my experience over the last 25 years, the effort we apply or avoid before we code has probably more impact on our software’s ability to meet business’ changing needs than any single factor, but that is not the focus of technology or the refinements of its use. So, while I do believe accelerating DevOps more and more is a good thing, it is not the main thing.
Either way, not hitting the mark is not hitting the mark no matter how fast you miss.
We used to say this often 20 years ago. Garbage in; garbage out. People seem to be weary of the phrase. The truth of it never wore off though. It is amazing how much faster many teams are at producing features that the business never wanted, or at least in the way they wanted it.
So, I will close by saying, we want success to be measured, not by how fast we can produce everything including crap, but how little crap we produced in proportion to the overall outcome. That is determined by the domain experts, not by your DevOps engineer or even your developers or architects.
If you want to know how good you are really doing in IT, don’t ask IT, ask the domain experts, the business process owners, feature by feature, on a scale of 1 to 10 how close IT hits the mark. They may be shocked you asked. Want to go a step further? Plan to prioritize the worst offenses.
If your team has a hard time hitting the mark, it is likely the staff is not a team with all who need to be there. If they are, maybe they don’t know how to design the software first. Maybe they don’t design at all, a sure way to produce junk. Maybe you have a translation issue between business and IT where the terms of the software are not the same as the terms in the domain. Either way, not hitting the mark is not hitting the mark no matter how fast you miss.
I help people overcome design deficiencies they may not even know they have. Let’s chat if you want to talk it through.
Until then…
References
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and devops: Building and scaling high performing technology organizations. It Revolution.
