Bryan Finster on Andy Patton's Antipatterns (Las Vegas 2020)

The playbook for digital agile cloud transformation (no prior experience necessary). The one best way, best practice program to digital nirvana. This week's guest is Bryan Finster. Jonathan Smart, business agility practitioner, thought leader, and coach, reveals patterns and antipatterns to show how business leaders from every industry can help their organizations deliver better value sooner, safer, and happier through high levels of engagement, inclusion, and empowerment. Sooner Safer Happer: Antipatterns and Patterns for Business Agility For Leaders At All Levels, In All Roles


(No slides available)


Jon Smart

Author, Sooner Safer Happier


Bryan Finster

Lead Value Stream Architect, Walmart Technology's DevOps Dojo, Walmart



Welcome to Andy patterns. Anti-patterns your playbook for your DevOps? Agile digital transformation. No prior experience is necessary. It's the one best way as practice program to digital Nirvana today, I'm joined by Brian Cranston, also known as Walter White from breaking bad. Obviously filming is finished now. So, uh, Brian is now the CIO at Walmart, not compliant.


I think you have me confused. Uh, I'm Brian Fenster, uh, Brian Cranston. He's unrelated. Uh, no, I'm not the CIO. I lead the DevOps dojo for Walmart where we actually help people.


Uh, Olivia, I thought you said we were getting someone important for this for the show




Was so, uh, so, so brain, you said your, um, so you, you do DevOps for Walmart? Uh, yeah. Yeah. Brian, Brian Finisterre. So you, you, you dev ops for, uh, for Walmart. Um, so I guess, so I guess obviously dev ops is a role, so that's clearly that's the role or in then, um, uh, and you know, in my experience, people need to be told what to do, you know, leaders know best, it's important to, um, mandate change. Top-down big bang, get it done quickly. You know, people generally can't be trusted. So I'm guessing then in your role, uh, from what you've just said there, I'm guessing you're the, if this was worldwide wrestling, that you'd be, you would be the dev ops dictator.


No, I don't think so. I think he actually needed trust people. You know, it takes a real community to, to really do a DevOps way of working. You know, if you've got dev ops as a role, you're most likely doing it wrong, it's much better to, to build up a community of engineers, a community of passionate people who can, you just really are focused on improving everything about their community, including their lives by developing in ways that are just better and happier.


Sorry, sorry, Brian, you finished?


Yeah, yeah, no worries.


Yeah. Sorry about that. Just a urgent call. Come in. It was the, it was the, and so, um, uh, so, so Brian, what do you, what do you measure? How do you measure success? So, um, you know, in my experience, um, yeah, and you know, people are inherently lazy and can't be trusted. So, um, something I've found to be very successful is to, um, incentivize people on the amount of features that they produce, um, feature driven, feature driven development. Um, some other typical measures that I have found to be very successful for increasing output is things like lines of code.


Yeah. I was going to ask if you measured that code.


Yeah. It's a, it's a great way to generate more code velocity, say, do ratio. That's very important, you know, are people actually doing what they say they're going to do? Uh, the word commitment is very important. Um, you know, the milestones milestones are a great tool for motivation. Um, deadlines drop dead date, uh, you know, real success is driven by people that can make their dates. Um, and, you know, uh, created some digital factories in the past because really, you know, producing software is no different from widgets rolling off the end of an assembly line. What are you, what do you think, Brian, do you, uh, do you, do you do that? Do you measure features?


Uh, no, no, honestly, uh, you know, users that, that your customers really don't care how many features you shipped, if they're crap, um, you, you know, you really should be focusing on the outcomes and the I'm really I'd like to help you with this, you, you know, are, are what we are, is what we're delivering, what the users need to improve their lives, you know, or are we doing in a way where it's stable and available? You know, we're giving them change frequently enough that they can get their jobs done. I mean, these are really important things, lines of code, uh, I mean you could measure lines of code and if you incentivize me that way, what I'll go do is I'll just code myself a Ferrari. It'll just be terrible, but I met your metric. I'd suggest not doing that. You know, a friend of mine, John smart, he's got this great book. You should read better values, sooner, safer, happier. And it's really focused on, you know, if you measure the right things and you, uh, you know, remove the waste and improve your efficiency, you can do what I tell teams that they can do, which is deploy more, sleep, better, have better lives.


Yeah, it sounds, sounds all a bit fluffy to me. You know, I think, you know, people, people generally will slack off happier. Absolutely. There'll be happier. Cause you know, they'll just basically be, uh, taking every opportunity to give the up at the appearance of work. Um, and that's why I think there are some fantastic tools at the moment, um, in terms of individual developer productivity measures. So I find this is a great way to identify the poor performers in the team. Now you have individual developer productivity measures, you're measuring key strokes. You're measuring when people are active at the keyboard, especially in the pandemic. There are some organizations who are tracking when people are actually active on their laptop, um, and what websites they're visiting, um, and some fantastic software to generate. As I said, individual developer productivity metrics. And then you can compare people. You can plot them, you can stack rank people and you can find the poor performers. Um, I think it's a motivational tool for performance


Driven development,


Fear driven development.


Yeah, no, I don't. I don't believe so. I think that that actually, uh, you'll find that if you focus on that your outcomes will be for your organization, your bottom line, your outcomes, much worse because if people are in fear, then your top developers to go someplace where it's a less toxic environment, you know, and, and, uh, you know, Mr. Sam, he has a great quote that, you know, in business team win, not, not people, it takes a real team to get it done. And if you're focusing on individual metrics and what you're going to get is individuals focusing on their metrics instead of what the team is trying to get done. So, you know, measure what you want, if you want good outcomes and measure the outcomes. If you want to measure people to find out whether or not you need to fire them, you know, do that, but you know, be prepared to go out of business.


Sounds like a bit of a fantasy to me.




Moving on from that nonsense. Surely it's just a case of rolling out Jenkins and Jair ribbon. You're done tooling, led transformation, 90% of the problem, shake and bake, highest performing team. You see what they're doing? You look at what tools they're using and then you get everyone else to work like that you impose one set of best practices across the organization,


Like a framework


Like a Friday.


Yeah. Uh, you know, if, if every team and the company has that exact same problem with the, the same business problem, with the same tech stack and the same people, uh, then you can absolutely have them all operate exactly the same way. But the reality is that's just not the case. Everybody has their own problems. Uh, the context is incredibly important. And if you don't really focus on the context, um, then you won't get the best outcomes, you know, allowing teams to solve the problem that they have. And so telling them how to solve their problem will be a much better outcome for you. I honestly, I would suggest you try that instead of


Yeah, I think there's, I think there are just best practices. There's the one best way. Um, and,


And no, no, if you found one best way, write a book because everybody will buy it, but I guarantee you, you haven't, um, and you can't solve it with a tool. No.


Yeah, yeah. Maybe, maybe a book on the one best way. Yep. Um, so, you know, people complain about culture. Um, I think it's really just a bunch of people winging, to be honest. Um, and you know, this so-called culture problem doesn't apply to leadership, um, is my view. You have, it's very simple, really. You get teams to agile maturity, level four on your maturity model. Um, and then once they've got to agile maturity model for, then you can start thinking about dev ops and then you can go DEO dev ops maturity, level one maturity level, two maturity level three maturity, level four, and then they have arrived. And then they are, you know, can't get any better than that, but obviously obviously certification, but certification certified, really agile practitioners. Um, uh, and then you might basically just mandate it top down to line to the maturity model. That's what I find. What'd you think Brian?


I think leadership is more, um, it's, it's more than just having confidence in saying you people need to change and if you're gonna lead, you really need to exemplify the culture of change. You know, you need to create an environment where people, uh, have the ability to make things better and encourage them to make things better and give them room to make things better and really lead the change by saying, these are the goals, the measurable goals that we need to achieve. Not all you people go faster. Honestly, it just doesn't work. You've got to set people up for success and trust your people, uh, and, and treat them like the skilled, uh, professional software engineers that they are. And, you know, we're not Legos.


Well, I could see I'm getting nothing for this conversation. And I think Brian, I think you should think about not letting your boss hear this for your own employment's sake. So that wraps up another anti-patterns anti-patterns your playbook for your dev ops, agile digital cloud transformation, no prior experience necessary, but one best way, best practice program to digital Nirvana tune in next time for someone who is slightly less disappointing than Brian.


Yeah, for sure. I'm looking forward to crushing you in the market.


Hi there, John smart here, Andy catheters, after building, if you haven't caught on Andy's my alter ego and advocate for anti-patterns that act as a headwind to delivering better value, sooner, safer, happier. Maybe you can identify with what Andy believes the best practices. Hopefully you're experiencing what our guests are advocating. And to be clear, my role as anti-pattern in this series is a hundred percent parody. All of the guests have signed up for the intentionally uncomfortable banter and insults learn more about these anti-patterns and patterns for better ways of working, leading to better outcomes in my book, sooner, safer, happier, available in all formats. I also encourage you to attend the virtual DevOps enterprise summit, Las Vegas, taking place October the 13th to the 15th, the DevOps enterprise summit events and community are near and dear to my heart. I truly believe it's one of the best places to learn from the actual experiences of our peers and to make new and lasting connections.