Continuous Delivery isn’t about how fast you can deliver, it’s about the outcome your delivery achieves. Bryan Finster, author of the 5-minute DevOps series and founder of the DevOps Dojo, joined our Dev Interrupted Discord community to answer your questions about outcome-based development, continuous delivery, and why failing small is better than failing fast.
Bryan is currently a Distinguished Engineer at Defense Unicorns but has also worked for Walmart as a systems analyst and eventually became a staff software engineer for Walmart Labs. He had previously appeared on the Dev Interrupted Podcast to further talk about these subjects as well as the most common pitfalls dev teams find when trying to optimize their delivery process. Listen to the episode here:
This Community AMA took place on January 8, 2021 on the Dev Interrupted Discord.
Necco-LB: Community AMA @everyone
Topic: Outcome-based Development with @BryanF (Bryan Finster)
Bryan, thanks for joining us today!
Bryan Finster: Thanks for having me!
col: Bryan… great quote. “A developer is a business expert who solves problems with code.” Thank you. Tremendous concept.
Bryan Finster: Thanks. That’s who we are. We aren’t Java spewing legos. If we don’t understand the business, the code won’t.
Rocco Seyboth: YES!! @col Love it. @oriker says “a business decision is made with every line of code”
Bryan: Exactly. How does this change improve the bottom line. Even more, how does it improve the lives of our customers?
Necco-LB: We really enjoyed having you on the podcast to talk about Outcome-based development and what continuous delivery should be trying to achieve. I was hoping you could explain to use what Outcome-based development means?
Bryan: It’s just focusing on the outcomes. It’s pointless to focus on how we do things if the outcomes are poor. It’s also about Hypothesis Driven Development. The act of defining the expected value before we attempt to deliver it and then measuring for that value. Instrumenting the application to see how close we get so we can adjust. I frequently see people just being feature factories, pounding out changes that no one needs. That just costs money and increases support. We should be deliberate about what we do and say “no” when the value isn’t obvious.
Cocco: When it comes to delivering value to the customer sooner, what things do you commonly see teams worrying about that they perhaps shouldn’t (or not worry about, when they should?)
Bryan: “I can’t release this! It’s not feature complete!” No, get the incomplete change out there and make sure it doesn’t break anything.
Necco-LB: You mentioned during the podcast that Pride is the best metric ever. Can you explain that a little bit?
Bryan: If I own the business problem, own the solution, own how to make it better, own the outcomes and see people getting value from my work, then I have pride in what I do. I want it to be good. I want it to be secure and stable and I want to continuously improve it.
Necco-LB: When you talk about outcome-based development you often talk about the things that need to happen before hands touch the keyboard. What are some of those things?
Bryan: We need to understand the value we are trying to deliver and we need to define how we expect to deliver that value at the detail level. It’s not enough to write a vague user story. We need testable outcomes that we agree should deliver that value. Behavior Driven Development is the most effective tool I’ve found for that. We also need to make sure we aren’t trying to deliver ALL of the value at once. What if we are wrong? We usually are, statistically. So, what is the smallest, highest value thing we can deliver to find out? Sometimes the right answer is to stop at that point. Invest in the outcomes, not the plan or the work.
_____________________
Read the unedited AMA and join in the discussion in the Dev Interrupted Discord here! With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. Join the community >>
_____________________
Cocco: What patterns/trends do you see in teams who can deliver the outcomes they want? (Are there common factors in teams you’ve seen that move from struggling -> successful?)
Bryan: Yes. Actual continuous delivery and product ownership. They can deliver small changes daily and they have ownership of what those changes are. They have the safety to challenge things without fear and they are not pushed so hard that there is no time to think of better ideas. Software development is a mental activity, not typing.
Necco-LB: You work with a lot of different teams at the DevOps Dojo. What are some of the most common pitfalls preventing a team from optimizing their delivery process?
Bryan: They are given the wrong problems to solve. They are asked to solve stupid problems like “how many changes did you make today?”, “How many stories did you complete this sprint?”, They don’t know how to work as teams because they are incentivized to work in silos. So, requirements are poorly defined, testing suffers, speed suffers. They need to be solving the business problem. What is measured will change. Be careful what and how you measure.
Necco-LB: What are some first steps a team can take if they want to become more outcome focused?
Bryan: Focus on the business problem and get close to the user. Empathize with them and what value they need. This really applies to anything. If you don’t respect your customer, you won’t need to worry about them for very long.
Necco-LB: What is the role/responsibility of the developer in this outcome-based development model?
Bryan: On a good development team you have engineers and product ownership. Engineers ship working solutions. They know they are working because they tested them, delivered, them and observed that their tests were accurate.
Rocco Seyboth: In 5 Minute DevOps you talk about observing what high performing teams do then modeling other teams to the same process and behavior… how do you reconcile that with the belief that every team is different and should have the flexibility to do things their own way?
Bryan: Actually, I advocate against cookie cutter templating of teams in that post. We should standardize on improving outcomes.
Necco-LB: Friends, that’s just about the top of the hour. Bryan has a real job that needs to get done, but feel free to keep the questions coming asynchronously throughout the day – he’ll be popping in and out to answer them. Bryan – thank you so much for joining our community today and answering our questions!
Bryan: Just some contact links to leave and I want to thank everyone for the conversation. I love talking about these topics.
https://www.linkedin.com/in/bryan-finster/
_____________________
Starved for top-level software engineering content? Need some good tips on how to manage your team? This AMA is based on an episode of Dev Interrupted – the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Listen and subscribe on your streaming service of choice today.
