Category: Blogs

I recently had a chance to sit down with Gary Gruver, well known DevOps leader and author. Gary’s new book, Leading the Transformation, Applying DevOps and Agile Principles at Scale is a great how to for managers looking to lead the transformation at their respective teams.  Gary put on a very informative webinar which you can listen and watch that goes into much greater depth than this short conversation.

I have posted both the audio file to listen to and a transcript of our conversation below.  Enjoy!

[soundcloud url=”https://api.soundcloud.com/tracks/224098337″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”450″ iframe=”true” /]

Here is the transcript of the conversation with Gary Gruver. You can follow along with the audio file or just read if you like:

Alan Shimel:         Hi. This is Alan Shimel, Editor in Chief of DevOps dot com, and welcome to another DevOps chat in our leadership suite. Today’s guest is DevOps thought leader, and well-known author, Gary Gruver, who has just published his book, Leading the Transformation, Applying Agile and DevOps’ Principles at Scale.

Gary, welcome to DevOps Chats.

Gary Gruver:                Hi Alan. Good to be here.

Alan Shimel:                Thank you. Gary, first of all, let me just commend you. The new book is great. I think I mentioned to you offline, I read it on the way out to California, and back. I went back and actually highlighted a bunch of stuff, which I don’t often do with books anymore, but it was that good and that important to me.

So great job on the book. For those of our readers who may not be familiar with both yourself and the book – why don’t you give us just a quick background and synopsis of Gary and the book?

Gary Gruver:                Well I’ve been in high tech for a long period of time and the last, probably eight years, leading large scale transformations of software development projects in different organizations, first at HP as the Director of the Imbedded Firmware Organization, over about – we started with 800 developers.

And I wrote my first book because the results and benefits that we saw with that were so dramatic, and I learned so much from the organization and the transformation that I just felt that I had to share it with everybody else, do that’s a practical approach to large-scale actual development. It’s kind of a case study at HP.

And that kind of gives you a feel, a short, quick, easy to read, not very technical book for executives that just – here’s what a transformation looks and feels like. I’ve gotten more actively involved in the Agile and the DevOps community and learned a lot by going to a large retailer, and was head of QA Release and Operations at that retailer, and led a large transformation towards continuous delivery there.

And what I found through the process is, it’s easy for engineers to go to different conferences and understand how to develop differently, but if the executives don’t engage in leading the transformation, they’re going to come back, and the organization is going to throw a wet blanket on it. So what I tried to do with the second book, which Leading the Transformation is, is write down and capture in a book that was short enough – 100 pages – so that executives would read it, but had everything I wished I knew before I started on my transformation. So look, there’s going to be uniqueness and differences with different organizations.

But the more they can avoid the bumps on the heads and the learnings that I’ve already gotten to on my own, and moved forward, and kind of moved the process and the technology forward, I think the more effective they’re going to be. So I created a lot of passion around trying to get some great business benefits.

And I really wanted to share with others and try to figure out how I could help others to be more successful too.
Alan Shimel:                Absolutely. So, Gary, one of the interesting things I got out of your book was – you know, many executives, they hear of the benefits of Agile and DevOps, and where do they sign up, right? Sign me up for that. I’d love to see those kinds of exponential improvements in all of these metrics.

But one of the things you say is – executives who are just looking to do sort of Agile in and of itself aren’t going to see that sort of success, correct? It’s not just doing Agile, if you will. As a matter of fact, if you say that you do just Agile, you’re probably not going to be very successful. Do you want to expand on that?

Gary Gruver:                Yeah. I would say it’s too large of a transformation and too large of a turmoil. If your current development processes are meeting all the needs of your business, you really shouldn’t go through this much effort and turmoil in your organization and cultural change.

But I think what most organizations are seeing is – they’ve got larger, and software has become more and more important to how they compete in the marketplace, that their current software development processes just aren’t able to react and respond to where they need to add value as a business.

And so, start with what is not being delivered to your business from your software development processes and your business objectives. You know at HP, it had been two decades that firmware had been the bottleneck for the business, and so we really started by saying – we want to be able to add a new product anytime we want without firmware being the bottleneck, and we wanted to free up capacity for innovation.

And it was with those business objectives that we were able to prioritize the things we went after, and I think if you start with your business objectives and fundamentally looked at the rest of your toolbox, whether it’s to add to laying DevOps, sort of combined automated – just any of those things are just tools in your toolbox that are there to solve a problem.

And then you go on a journey of continuous improving. That’s where you get the business results. It’s not going after one of those principles and hoping that you’ll get business results. It’s driving for business results and using the tools as appropriate.

Alan Shimel:                Got it. And Gary, you use the term a lot, continuous improvement. In a world where continuous is the new black, and we hear about continuous delivery, and continuous integration, and continuous testing, and continuous security – briefly, what is continuous improvement?

Gary Gruver:                Well it’s really wanting to go out and learn what’s between you and your organization delivering software better and more effectively. And then it’s constantly just chipping away at those barriers and learning and getting better involved. You’re not going to know everything.

You know, at HP, we got two to three X improvements in productivity, but we didn’t go off on a three year plan to make that work. We took it month by month, and assessed some objectives, and tried to get better. And you’re going to learn so much as you really start getting out there in trying to figure it out that, what you’re going to find is, if you create a three year plan, or even if your could, it’s going to inhibit you from getting better because you’re going to learn something new that was getting in the way.

And so, don’t try to lock in too much. Software developed and improved effectively can be very flexible and responsive. Learn and adjust, and learn and response, and just take on the biggest barriers to your productivity one at a time. And when you improve that, you’re going to learn what’s next and continue to improve that.

But it’s getting the executives to come together once a month to review what they said they were going to get done, what got done, and what didn’t get done, and what you’ve learned in the process, to set the objectives for the next month. You know, at HP, we went off trying to get 10X better, and we did it a month at a time.

And when we looked back three years later, we had gotten, you know – my co-author would say, 10X better in terms of frequency, and builds, and those things, but business results – easily 2 to 3X better, but it wasn’t by executing a four year plan, it was by getting up after continuous improvement, and learning and adjusting along the way.

Alan Shimel:                Sure. You know Gary, in the book, one of the things I got out of it is, you sort of refer to CD, continuous delivery, as a lot of the tools and maybe processes that we follow along this Agile and DevOps journey, if you will, or process. But DevOps specifically is largely cultural in the book anyway. Is that correct?

Gary Gruver:                Yeah. It depends on whether you’re talking to Gene or Jez. Jez will focus more on the technologies, and Gene will rely on the culture. I can’t really separate the two. You can’t get the cultural changes without the tools, and you can’t implement the tools and get the benefits without the cultural changes.

I like the definition where you just lump them together and say – it’s the cultural and technological changes that enable us to release code on a more frequent basis, in a more stable way, and get feedback from our customers on an ongoing process. And so that’s the definition that kind of resonates with me, and I have a hard time getting between the two.

But you know, in a large organization where you’ve got tightly coupled code that requires people to develop, qualify, and deploy in unison, the technologies of continuous delivery, whether you deploy everyday or not, is the forcing function that ensures all your code is going together and stays aligned.

And so the first order of effect in a large organization is to help it come together to deliver code, or deliver value to their customers, on an ongoing basis. And the second order of effect is how the individual teams work, continuous delivery, and some of those principles are the forcing function that allows working code to provide that alignment across a larger organization, and not develop code that either won’t work together or won’t work in a production like environment.

Alan Shimel:                So Gary, another sort of debate – and I don’t know if it’s a Gene and Jez debate, but it’s certainly within the community – is, do you do DevOps from top down, bottom up? Do you do it from both and meet in the middle? You have a very unique perspective in having led several transformations now and, obviously, you come at it from a top up perspective. What should leaders, listening to you here today, what should they take out of that?

Gary Gruver:                I think if they’re going to be successful, the leaders need to lead it because you can’t have some groups decide to do it, or some groups decide not or do it in a different way, if their code has to come together and be delivered as a unit. But, at the same time, it’s not management.

It’s more lead it. Set the direction. Set the priorities, and engage with the organization to learn what’s working and what’s not working. And so, you know, the continuous improvement, executive-led continuous improvement process I describe in my book really shows how the executives engage in the organization to lead that because you need all the learnings in everything that’s getting in the way from the bottom.

And you need kind of the set of priorities from the top, so it’s that constant interaction between the leaders and the organization that gets all the best ideas and all the learnings out on the table, that gets you to prioritize the right things and go after the right improvements.

Alan Shimel:                Yeah. Gary, the last chapter in the book is entitled, Getting Started, and it kind of represents, okay – after you’ve learned what you can from this book, here’s how you can get started in your organization. Of course, people should read it for themselves and learn from it, but what can you take out of that last chapter to give people a jump start on that?

Gary Gruver:                You know, you really need to start where the most pain is. And one of the things that DevOps causes you to do is do things more frequently. And what you’ll find is your organization has been brute forcing its way through the same issues for years. And as you start to increase the frequency, you’ll have to start fixing that.

And it’s hard to tell. For different organizations, it’s different places, which is why I put that piece at the back end because it depends on what you already have in place. If you’ve got a web micro services architecture that enables teams to work independently, it may be as easy as a cultural shift, and putting an operations person on that team, and letting him own things end to end.

If you’ve got a more tightly couples system, you’ve got to think about how do you coordinate the work across them? And the first step may be, can you do continuous integration of as much of the enterprise system as you can, with a few simple tests? And make sure you’re automated correctly. So it’s that step of learning and evolving. And then as you try to do it and increase your frequency, you’re going to find different pain points.

And that’s why I’d say it’s the continuous improvement stuff. And you know I do work shops with different executive teams to really try to bring out, and try to understand their development processes to the point that we can figure out where to start the continuous improvement process.

We hold a work shop with their technical and manager leaders and everybody in the organization, and try to really nail – what’s that first month’s objectives? And then we do ongoing mentoring calls for the first six months to make sure they’re off on the right path.

But you know, as opposed to spending forever trying to figure out where to start, if you can think about starting your continuous improvement process, even if you pick the wrong things first, you’re only going to go down that path for a month before you have a chance to learn, and adjust, and go after the things that are really in the way between you and your organization being productive.

Alan Shimel:                Great. Hey, Gary, we’re about out of time.

Gary Gruver:                Okay.

Alan Shimel:                Thank you very much for appearing on today’s DevOps chat and, again folks, the book is, Leading the Transformation, Applying Agile and DevOps’ Principles at Scale. And for any executive or manager out there who is contemplating or perhaps is already engaged in leading a transformation around Agile and DevOps around software development, I highly, highly recommend it.

You can get the book on Amazon. It is from IT Revolution Press, and just Google it. I think we also have a two chapter download, which we’ll put a link to up on the webinar page for this. Gary Gruver, thank you very much. This is Alan Shimel, of DevOps dot com. Have a great day.