Outcome-based Development with Bryan Finster

**SPEAKER_1** (0:01)
Continuous delivery isn't about how fast you deliver, it's about the outcome your delivery achieves. We're kicking off this new year by talking about outcome-based development and why failing small is better than failing fast.
Joining me for today's discussion is the author of Five Minute DevOps and founder of the DevOps Dojo, Bryan Finster.

**SPEAKER_2** (0:23)
This episode is sponsored by LinearB. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**SPEAKER_1** (0:37)
Hey, Bryan, thanks for joining us today.

**Bryan Finster** (0:40)
Thanks for having me.

**SPEAKER_1** (0:42)
Awesome to have you here. Read a bunch of your articles and I see that you're really helping out the community, which we totally appreciate on Dev Interrupted. I wanted to get right into it.
So I know in the past, you've talked about outcome-based development, kind of the idea of defining maybe the value of the delivery even before the coding starts, something like that. Can you talk more about the idea of outcome-based development and why it's meaningful to Dev teams?

**Bryan Finster** (1:16)
Well, I mean, if you look and read continuous delivery, they talk about hypothesis-driven development and really what you're trying to do is you're saying, okay, if we do this thing, we expect this outcome. Our job isn't just to push code. We're trying to solve business problems and deliver value. We can't come up with what that value is upfront and then figure out a way to identify whether we deliver that value at the end. Then all we're doing is just feature factories. We don't want to be feature factories.
I've been a developer for a long time and the thing that really speaks to me is delivering value to the end user. That's what it should all be about.

**SPEAKER_1** (1:51)
Yeah, it's actually interesting that you mentioned continuous delivery in that way. A lot of the times when I hear someone say something about continuous delivery, not all the time, but a lot of the times they'll say something like, well, it's about how often you release.
Or it's about some kind of metric. Not too often do I hear someone say, well, it's about value.

**Bryan Finster** (2:19)
Yeah, it's 100% about value. I mean, continuous delivery, I hear this all the time too, where people focus on the tools.
And they say, we're doing continuous delivery because we have a Jenkins pipeline. No, you're doing continuous delivery because you have an idea, you deliver it to the end user and get feedback as rapidly as possible, that you're optimizing that entire loop and trying to shrink that loop to make it more efficient so you can get faster feedback. It's all about minimizing the time between when you do something, when you get feedback. That's what CD is for.

**SPEAKER_1** (2:52)
Right, right. And it's probably important, like who you're getting feedback from or what is the feedback that you're looking for?

**Bryan Finster** (3:00)
100%. I mean, I talk all the time about, you know, I had, when the MacBook 2017 came out, I bought a refurbished 2016 because the 2017 didn't have an escape key. So to me it was poor quality.
That's what quality comes from. You're trying to get quality feedback from the people who actually use your thing.
And you have to do that fast. You can't get quality feedback by testing. You get feedback on the tests by delivering, but quality comes from the end user. And that's what you're trying to do. How fast can they get that feedback?

**SPEAKER_1** (3:35)
Right, right. So if we're taking it back to outcome-based development, as opposed to just like, you know, kind of hollow CICD releases, what are some of the characteristics or what are some of the things that teams should be doing if they really want to be focused on those outcomes?

**Bryan Finster** (3:58)
We're measuring what we do and not just the value at the end, but how we achieve that value. Metrics are core.
You know, I'll tell anybody who asks that my two favorite topics when I'm doing this, testing and metrics. Because if I'm blind, I'm just doing things, but I'm not measuring it. But every single step of the way, how can we measure improvement? How can we find waste in the flow and remove that waste? And then how can we get feedback from the user to find out if we can be super efficient? That's fine. But if we're not effective, it doesn't matter. We're just efficient at delivering waste to the end user.
And so coming up with what those metrics are, measuring those things with the goal towards improvement, and especially for leaders, not with using metrics as a goal, but using metrics to help the team find things that they can improve.