⬅️ Fuzz Jam June 🧭 Shock the Chaos Monkey ➡️
Can't Buy Me Lead Time
by Jay CuthrellShare and discuss on LinkedIn or HN
Music: The Beatles - Can’t Buy Me Love (1964)
This week we take a look at the importance of lead time as a metric on a path to DevSecOps, platform engineering, and product-led culture.
Getting Informed
For most folks, the term “lead time” might come up when they order something. For example, your ordered something physical and the thing’s manufacturer or supplier replies that they are experiencing longer “lead time” on a particular something — meaning you will wait longer until your consumer satisfaction is achieved.
Within software application development teams that embrace DevOps cultural attributes, it is increasingly common to hear about measurements. One measurement in particular borrows the terminology for the latency between the start and end of a process — and is referred to as “lead time”.
Now it’s time for reading 📖, watching 📺, and listening 🎧 suggestions:
📖 - Blog posts
-
First, 📖 A New Approach To Measuring Developer Productivity in which Abi Noda continues to highlight recent research worth checking out in depth.
-
Second, 📖 A Getting Started Guide to Establish an Internal Product Culture in which Ben Voss continues exploring internal developer platforms _as products_.
🎧 - Podcast episodes
-
First, 🎧 The Intersection of Supply Chains, 3D Printing, and Sustainability in which Tom Raftery interviews Len Pannett and brings to mind many analogous parallels to the software product world.
-
Second, 🎧 Unleashing Team Potential in which Kevin Gentry and Lou Cirillo talk through lead time (and cycle time within), deployment frequency, mean time to restore, and change failure rate referenced in a Dan Olsen talk with Marty Cagan (a meta critique of the third video below!)
📺 - Videos
-
First, 📺 Lead Time and Cycle Time in which Anil Jaising of Concepts & Beyond shares dining experience analogies to make us all hungry (to learn more!).
-
Second, 📺 Devops - More than the tools and tech in which Martin Comstedt of OnBird makes the case that tools and technology alone are not the entire story of DevOps principles and measurements (and uses a flip board!).
-
Third, 📺 Major Misconceptions about Product in which Dan Olsen talks with Marty Cagan in a super spicy 🌶️🌶️🌶️ Lean Product Meetup (with 30 minutes of equally super spicy 🌶️🌶️🌶️ audience Q&A!)
I’ll get you anything, my friend 🎶
To be clear, definitions for “lead time” might vary depending on perspective and who you ask within a software application oriented supply chain. For some the “lead time” is a measure of going from ideas to realities and for others there are far more granular definitions.
If “lead time” was related to was a physical item you ordered, getting it faster is one thing. However, getting it faster but missing parts or with a defect that puts you at risk is not acceptable — quality assurance and security matters.
An insufficiently cooked meal _could_ arrive faster. But, would you really want to eat it?
Being faster still requires care across quality and safety/security dimensions.
But what I got I’ll give to you 🎶
I like to say that “lead time” can be thought of as the measurement of _the time between when a developer contributes to the product experience until an end user of that product experiences **a desirable impact** from the developer’s contribution_.
Of course, as the modern hybrid cloud experience drifts towards greater SaaS and PaaS with further abstraction of IaaS, it is reasonable to expect “lead time” expectations to be increasingly top of mind for business leaders charged with digital transformation.
Or, as I was saying…
http://www.techmeme.com/230706/p35#a230706p35
To be clear, getting a shorter “lead time” should not be due to lowering quality or completeness — and cannot be the result of bypassing security considerations.
So, I’d argue that DevOps pursuits should, holistically, be DevSecOps pursuits rooted in secure software development practices combined with quality engineering, automation first thinking, and — long term — seek to become platform engineering pursuits on a path to express a more product-led growth culture.
So, what will be the next big thing in “lead time” and related DevSecOps, platform engineering, and product-led culture measurements?
Until then… Place your bets!
Disclosure
I am linking to my disclosure.
🤓
Topics:
✍️ 🤓 Edit on Github 🐙 ✍️
⬅️ Previously: Fuzz Jam June
➡️ Next: Shock the Chaos Monkey
Share and discuss on LinkedIn or HN
-
Get Fudge Factor each week