Gary Gruver has partnered with Dave Farley, co-author of “Continuous Delivery,” to supply trainees with key software design patterns and an understanding of how to avoid common mistakes along the way. This curated, wiki-style content library is based on Farley’s breadth of knowledge and decades of experience; Alan, Gary and Dave discuss. The video and a transcript of the conversation are below.
Intro: This is Digital anarchist.
Alan Shimel: Hey, everyone, it’s Alan Shimel. Welcome to another TechStrong TV segment, here. I’m joined by an old friend a new friend, today, that I wanna introduce you to. Both of them are actually very well known in the dev ops world and to our dev ops audience, but let me introduce them to you. First, I wanna introduce you to Mr. Dave Farley. Hey, Dave, welcome to TechStrong TV.
Dave Farley: Thanks. Nice to be here.
Alan Shimel: Pleasure to have you on. Dave, for those who may not be familiar with who you are and kind of, you know, where you are in the world, why don’t you share, if you can, a little bit of your background.
Dave Farley: Sure. My background is as a professional software developer, for many, many years. Mostly, at probably the more difficult end of the spectrum in terms of the kinds of systems I was involved in building up. I led a team that built one of the highest performance financial exchanges in the world. But I’m probably best known for as being one of the authors of the continuous delivery book, which introduced dev ops and continuous delivery to many people. And I’ve got a new book coming out, soon, on software engineering, as well. So, I think and talk about continuous delivery, software engineering, those kinds of things. These days, I run a consultancy advising big companies on how to do this kind of stuff better.
Alan Shimel: Fantastic, and welcome, and thank you. Next up is one of my older friends, not that he’s old, but I know him for as long as I’ve been doing devopsy.kinsta.cloud, and that’s going on eight years now. He’s well-known dev ops author, dev ops practitioner, leader, Gary Gruver. Hey, Gary, how are you?
Gary Gruver: I’m doing great, Alan. It’s good to see you again.
Alan Shimel: Yup, I did my best to embarrass you, but why don’t you give people a little bit of your background.
Gary Gruver: [Laughs] Well, you said I’m old, and I am kinda old, and I’ve been in this space for a while, and I’m not any smarter than anybody else, I just think I’ve been making mistakes in this space longer than anybody else. So, you know, probably where you hear the most about me is the transformation that led at HP, where we got a 2x to 3x improvement productivity leading a group of 800 developers around the world. And where Dave comes into this starting at the keyboard and working his way up, I start at the leadership level and working my way down towards the keyboard, but never quite on the keyboard type of thing. And, you know, really started doing things that later became dev ops, not to do dev ops or not to do CD. We were just trying to make the organization more productive and figure out what worked. So, years of trying to figure out how to help people realize the types of benefits that we got at HP with that type of transformation.
Alan Shimel: Sure. And then, I mean, not to be your agent here, but from HP, you also went to macys.com and helped build that out from a dev ops perspective, and you’ve written several books around your experiences at HP and Macy’s and others, on leading the transformation and, you know, making the transformation. And I should note that that was before Covid, B.C., right, it was B.C., and before digital transformation became the buzzword that it has, you know, since Covid.
Anyway, gentlemen, welcome, both of you, here. You guys have an announcement, some news we’re gonna break. Which one of you wants to go first?
Gary Gruver: Well, let me give it a try, since I kind of started this.
Alan Shimel: Okay.
Gary Gruver: You know, [crosstalk] all of my time, whether it’s books or webinars or keynotes or whatever, I’ve been trying to help as many people as I can on this journey, because of the benefits that we realized. And, you know, I came up – what I realized is people weren’t making the progress that I felt like they needed to be. And what I realized is, I started looking at other industries, whether it was the manufacturing industry or organizational change management. One of the things that was out there was I realized that, in the 1980s, the automobile companies in the US started getting attacked by Japan and really losing out on quality, and they came to the conclusion that, you know, we really needed to copy what Toyota was doing. And they spent years doing that, and it didn’t work, which feels a lot similar to what we’re doing in software. We’re going and looking at the people who are doing it well and trying to copy what they did.
Eventually, manufacturing realized the key to success was not copying, but coming up with a systematic approach to continuous improvement. So I’ve been really focused on that, and trying to do it in a way that overcomes the resistance to change, and coming up with a systematic approach and getting people excited about it. And then once people get excited about it, we really want’em to be able to be successful implementing these changes. A lot of them are new, and I’m looking for somebody that understands more, at the technology level, how to make all this stuff happen. And I ran across Dave and started reaching out to him, and what we realized is we started in different times and different places, but we ended up in a similar place, because they were the things that worked.
And so, we’ve come together to create a training program to help people, and we’re both at a similar point in our career where we wanna help as many people as we can, and we continued to do that through traditional engagements. But we realized if we digitized this content and made it accessible to everybody, we could help more people and it would be more affordable for them, if they could learn how to do it for themselves instead of needing the hands-on engagement.
Alan Shimel: Very cool, very cool. Dave, you wanna kind of fill in some of the gaps, here, or a little color to this?
Dave Farley: Yeah, sure, so as Gary said, we kind of come at this from slightly different angles, but tend to have coevolved similar approaches. I’m a technologist and I think in technical terms, and I think that some of the ideas that underpin the approaches that Gary and I talk about have some fairly deep reasons why they work. I think that continuous delivery, in particular, and the kind of engineering approach to dev ops that I talk about is genuinely, defensively an application of scientific-style rationalism to solving problems in software, which is something that I would call proper software engineering. And if that were the truth, then we’d expect to get better results by doing that, because that’s how engineering works
the disciplines. And I think we’ve got that.
I think that if you followed our advice, we can’t guarantee you success, but we can guarantee you that you’ll have a better chance of success if you follow our advice. Because I think that’s the kind of input that we can deliver, with the approach to software development that we describe. It’s the approach that underpins many of the organizations that we think of as exemplary at software development. This is how the best organizations in the world practice software development. And Gary and I have been doing this for a long time and advising people for a long time, and as he said, we came to the conclusion that we’d be able to help more people by trying to digitize some of our understanding and knowledge in a way that can help more people, you know, than we can just do talking to them as consultants.
Alan Shimel: Sure. You know, interestingly, you know, we’ve recently gone through a whole rebranding here, and we’re now the TechStrong Group and part of TechStrong TV, and we have TechStrong Media, TechStrong Associations, TechStrong Education. And as part of that exercise, we’ve been talking about just the whole way people learn today, right? I grew up where you wrote a whitepaper, right? A company wanted to tell you about their product, I wrote a whitepaper, or a series of whitepapers. When was the last time any of us read a whitepaper? You know, when was the last time someone wrote a whitepaper? But anyway, forget whitepapers for a second, just education in general, right?
We went from, you know, in-person being the only way to do education. You know, we always understood people learn, you know, via vision, via hearing, or tactile via touching. We went from that in-person education to online education, we went from formal certification to informal learning as you go, we have virtual reality, augmented reality education, anything goes, love is love. But, so, I gotta ask you guys, how are you packaging this? How does our audience consume this? And why did you choose that particular methodology or method?
Gary Gruver: Well, it starts with the white belt training, which is computer-based. And what I realized, when I was writing books, is I was hoping people would get’em and engage and then start reading them as an organization. And what I realized is, people would buy the books, and they’d sit around and gather dust. And one of the challenges is, how do you get people to absorb the content as it’s a computer-based system that can be integrated into your learning management systems, and there are large organizations that have integrated it into their employee development. So they buy an enterprise package and they’re having everybody take the training, and that’s a process that doesn’t tell them what to do, but it teaches them how to make their processes visible, and make the waste and the opportunities for improvement visible for everybody so they can align on those improvement ideas.
And that includes videos and texts, and more importantly, it’s scenario-based assessments: “If you are this person in this role and you saw this data, what would you prioritize doing?” And I came up with a lot of those scenarios based on things that I saw customers doing in the industry that I interacted with. So it shows how to use the views of trying to identify it, but it also shows some of the things that people are doing wrong. So it helps to highlight those types of things, and we put that together, and then, you know, we leveraged a little bit off of Lean Six Sigma and manufacturing, not in exactly what to do, but with the idea that, to get higher levels of certification, you really need to do an improvement project.
It’s more than just understanding the concepts and repeating them back. You’ve gotta go do a four- to six-month improvement project where you identify the issues, you highlight the problems, and you go to fix something, and you have metrics that quantify it. And the initial green belts were coming out with they’re saving, you know, over $50,000.00 in annual savings a year of waste _____ from the organizations. So we’re trying to motivate as many people to do that. And then, as we get’em motivated, we pulled in Dave to help’em avoid common mistakes and struggles along the way, and I’ll let him talk to that.
Dave Farley: Yeah, so you were talking, a little bit earlier, Alan, about the start of the pandemic, and the start of the pandemic triggered me into starting a YouTube channel. And I started recording videos, short videos on different aspects of software engineering, continuous delivery, dev ops, software development, those kinds of things. And that kind of led me to kind of thinking more seriously and taking more seriously the ideas of education and the ways in which I can help more people do more stuff. And Gary reached out and started explaining his ideas about the white belt training, and so on. And so, I started working on that material that can help with those separate improvement projects, to allow people to solve problems. So, we’ve come up with a bunch of tools that will allow people to explore different ideas.
So, my part of the offering is a multimedia wiki that will allow you to explore ideas as a wiki normally will and kind of jump around randomly. But also a bit like, when you’re going to visit the hospital and you follow the yellow track to get to x-ray, there are paths through the information that, if you follow those paths, they will guide you and give you advice on different ways of solving different parts of the problem. And that’s gonna be growing, over time, as we add more and more stuff, but already there’s a lot of useful information that can help people do things, like do more effective approaches to automated testing beyond deployment pipelines. And adopt the approaches of dev ops and continuous delivery into their discipline, and start to think about this engineering approach that we’ve both been talking about.
Gary Gruver: And what I really like about it is there’s specific design patterns, but there’s actually code you can look at. So you can see why Dave coded it a way, and the implications of not coding it that way. ‘Cause we don’t want people to get excited about making improvements and go forward and to get frustrated and get stopped, and we don’t want’em to create something that’s really hard to maintain and brittle. So we wanna try to – we can’t answer all the technology and we can’t tell them how to do it, but if – you know, Dave’s been doing this for a lot of years and has done it wrong a lot of times, and so, if he can help people avoid those mistakes, they’re gonna be more successful and more likely to continue along their journey.
Alan Shimel: Fair, fair. Guys, is this available now?
Gary Gruver: Yes, and there’s another thing that I’ve struggled with. One is, how do you get leadership engagement? Right? For leadership engagement, they’ll say, “Yeah, go do safe, or go do this, or go do that, copy what they did, and I’m gonna measure you and I’m gonna drive you on metrics,” but the leaders don’t really take the time to engage and truly understand the problems. And it’s so important to do, because, you know, because the same team does product development and improvement of the process, the process improvements always get traded off. And we call that technical debt. In manufacturing you have different groups, but you have a group very focused on the process.
If we can’t get the leaders to understand the opportunities for doing the process improvements, we’re not gonna get’em to champion that and put it in perspective with what they’re being demanded from the product standpoint. So we wanna get the leadership engaged, and we’ve tried to prototype processes working in a few large companies where they’ve had a lot of success. Well, we let the executives take the training together as a team, and we don’t say, “Go do the training,” ’cause it’s eight to ten hours and they’ll never get it done. We’ll say, “Can we put one more meeting on our agenda and we’ll do the training together, every week, for an hour. And then, it’s not just the training. We have somebody take the training ahead of them and bring examples from their organization.
So it’s not just training for training’s sake. It’s, like, “Okay, here’s a way of thinking about it and viewing the problem, and here’s that applied to our organization,” and then we leave’em time to debate. And it takes a little longer for’em to get through the training, but the alignment across the executives goes much quicker. And this, having done a lot of these transformations, this executive alignment is so important that I’m willing to offer a free prototype of the training to any organization that can get a group of executives committed to it, and has a change management person who’s willing to lead it and start to collect the data to facilitate those conversations.
And that’s available now, and you could just send the e-mail at garygruver.com, and I’ll help you get set up with the prototype. And the training’s available at garygruver.com, or you can go directly to engineering the digital transformation, and get all this training and certification that is available and is being used successfully at large companies today.
Alan Shimel: Very cool. So it’s garygruver.com for the information, here.
Gary Gruver: Yeah.
Alan Shimel: Cool. Guys, we’re almost out of time, but I gotta tell ya, I’m really stoked to have the both of you together on this. I think it’s a powerful testament, right, that this is gonna be something that’s worthwhile, if the both of you are the folks behind it. So best of luck with it. Guys, you gotta come back on and give us a progress report, maybe in a month or so, what do you think?
Gary Gruver: Yeah, sounds good to me.
Alan Shimel: All right. All right, go check out, look, if you’re interested in learning and learning right, about continuous delivery, about dev ops, about, you know, leading the transformation, engineering the transformation, check out this series of questions. I think you’ll find it worthwhile. Gary, Dave, thanks for being on TechStrong TV. We’ll talk to you soon.
Gary Gruver: Sounds great. Thanks for having us, Alan.
Dave Farley: Thank you. Bye.
Alan Shimel: Bye-bye.
[End of Audio]
