Agile has a bit of a longer history and subsequent maturity than DevOps. Despite this, how can an organization say that it is in fact an “agile organization”? What does that even mean?
Our guest on this DevOps Chat is Jeff Dalton, founder of Broadsword consulting, author of “Great Big Agile” and founder of AgileCXO. Jeff shares with us his latest venture, which is building AgileCXO into a worldwide movement to certify that organizations are, in fact, practicing Agile with best practices. Have a listen.
As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Transcript
Alan Shimel: Hello, everyone, it’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat is, I think, gonna be a good one. We have with me author, founder Jeff Dalton of the AgileCxO. Jeff, welcome.
Jeff Dalton: Good morning, Alan. Thank you for having me, sir.
Shimel: Absolutely. My pleasure having you. Talking off mic, we both lamenting freezing down here in Florida, but, you know, first world problems. It’s gotten into the 50s; we’re breaking out the cold weather gear.
Dalton: Yeah. Right?
Shimel: There was a time in my life where, if you told me it was 50s in January, February, I’d be out running around.
Dalton: Go to the beach?
Shimel: Yeah, pretty much. But, anyway, such is life when you move to Florida, Jeff. But let’s talk a little bit about the AgileCxO. First of all, let’s assume some folks in our audience are not familiar at all with it. Talk to us. What is it?
Dalton: Sure. AgileCxO.org is an organization that we started about two years ago and it was based on the notion that leaders really struggle with how to successfully create Agile culture in their organization and it was based on a series of about 200 assessments we did of Agile organizations to try to really figure out why it wasn’t taking hold in the way leaders wanted it to. And the conclusion we came to was really simple, really, is that Agile leaders weren’t being Agile themselves and they really didn’t know how to be. They need help with that, so there’s lot of reasons for that and we talk about that in the book, “Great Big Agile,” but that’s how we started about two years ago.
And, since then, we’ve developed a series of models for performance and for evaluation and a series of training courses. We have partners in China and Japan and India and the US now, delivering these services to their customers, so we’re pretty excited about it, and, now that the book’s come out, we’re even more excited about it.
Shimel: Absolutely. So, Jeff, for some of our folks out there, they hear people say, “I wrote a book,” right? And you know what? I’m blessed to have a lot of friends who’ve written books; I’ve contributed to several books. And people say, “Oh, yeah, that guy wrote a book.” They don’t really understand what goes into writing a book, though. I mean, right? I mean, it’s one thing to write a blog article or something like that. Writing a real book is work, though.
Dalton: It sure is.
Shimel: Share with our audience a little bit, what was the effort required here _____ _____ —
Dalton: That’s a great question. I’ve never been asked that, but it’s funny. I started my book with the—you know, you have the acknowledgements in the front of it and the very first line was “Writing a book is much harder than I thought it was.” [Chuckles]
Shimel: Yeah, it is. No, it is. I mean, there’s no doubt.
Dalton: You know, I’d written a lot of articles, lot of long articles. You know, I write a lot for Cutter IT Business Journal and for Better Software magazine and per week. And I’ve written quite a few articles in my life and I’ve written quite a lot for e-books, but what I really wasn’t prepared for was the sheer volume and effort associated with telling the story in completeness. You know, it’s one thing to kick one idea out in a blog post or to kick a series of ideas out and explain ’em, but to really explain a system of ideas and provide supporting information and research and really tell a convincing story, from start to finish, is a massive effort that I didn’t even do alone. I had help. I had—you know, my wife’s an editor and she really helped out, and I had other people on our team really help, providing me with information and reviews.
And that doesn’t even consider the publisher, who kept coming back with demands for more information and better clarification and really kept me on track there. And then there’s artwork and covers and indices. And I know, at the very end, they’re like, “Oh, you need a glossary”; I’m like, “Oh, okay.” So it’s a massive, massive effort, but it’s also a really cool effort because what I’ve learned from writing the book, one, is that you don’t really know what you’re talking about until you’re forced to flesh it out in writing.
Shimel: Yeah. For sure.
Dalton: And it’s really helped me working with my customers and clients because I’m able to really articulate what I think. And this is important because the book is about a new idea that people aren’t talking about that much. And a lot of people are talking about Agile—a lot of people—and there’s a lot of fantastic books about Agile. We didn’t wanna write another one. We thought that Ken Schwaber’s book on Scrum is beautiful and doesn’t need much elaboration and there’s books on DevOps that are very well done, and we didn’t really wanna write another one of those. I wanted to write about something new, so thinking through that entire story required a lot of effort and time and much more than I expected, but it finally comes together. At some point, you get in a groove and then it just becomes a mission. And we completed that mission in October, so.
Shimel: Good for you—
Dalton: A book came out the other end, so it’s pretty exciting stuff.
Shimel: Absolutely. But, you know, what’s kinda different in your case, Jeff, is the book really serves as the bible, the how-to, the map of this whole AgileCxO, as we were talking about. Agile in a vertical, I think, is how you mentioned it. Agile in a vertical way, not the usual horizontal, if you will.
Dalton: Right. Yeah, one of the things I talk about in the book early on is really trying to position the different industry models a little bit more succinctly because we hear about process models or behavioral models and frameworks, and there’s a lot of ambiguity in the industry about the differences between these things. “What’s the difference between Scrum and Agile?” is something you hear people talk about a lot and “What’s the difference between ISO and CMMI and PMBOK and all these different techniques and models out there?” And we categorize these things into three different categories in the book: what we call “why-ability” models—why are we doing stuff?; “what-ability” models—what am I supposed to do?; and “how-ability” models—how am I supposed to behave?
So you take something like an ISO or a CMMI or a PMBOK, these are squarely what-ability models—you must do these things; there’s a list of things that you’re supposed to do—but gives very little guidance on how to do it, what kind of behaviors are necessary. And a lot of the Agile frameworks are really great why-ability models—you know, “These are Agile values and here’s why you should do these things”—and they’re very light on the “what” because they wanna be more empirical and they wanna have teams learn and improve and change, as it makes sense. But there isn’t a lot of detail for a leader to say, “How do I make an Agile organization?”
So we coupled that with the notion that scaling Agile is really about scaling vertically, from teams up to senior management, not so much scaling horizontally, which is what we see with things like SAFe or LeSS. These are all great models and they’re necessary models, but the conversation’s really been focused on horizontal scalability, but nobody’s really talking about vertical scalability and the changing of leadership. Though we talk about being change agents and changing companies, when we do Agile transformations, but what we’re not doing so well is changing leadership.
Shimel: No.
Dalton: And that’s the primary impediment. I mean, if you look at any major study, like the VersionOne study—people talk about that one a lot—they’ve been saying for years, they’ve been raising this flag for years, that leadership is an impediment. And Cutter IT Business Journal just did a whole series of articles—I wrote one of them—about the problems with Agile leadership, so nobody’s really been addressing it, other than in the trade magazines. So we decided to write a book about it, and we’ve had a lot of experience. I spent a lot of years at Ernst & Young, doing leadership coaching, and we’ve had a lot of experience working with senior management, so we said, “Hey, they need help understanding this,” and so we wrote a how-to book for them. And that’s what it is. It’s called Great Big Agile and it’s actually filled with lots of pictures and it’s in color and it’s really designed for a senior manager to use as a reference.
Shimel: Fantastic. And we’ll get into where the book may be available, how some of our listeners listening in, if they wanna grab a copy, where they can, but I think the other thing I wanna convey to the audience, Jeff, is that this book doesn’t exist in a vacuum. It exists—
Dalton: Right.
Shimel: Right? It exists within the larger universe, as you mentioned, of other Agile books and DevOps books and a lot of, as you call them, these horizontal frameworks and so forth, but the book itself has kinda served as, again, a blueprint for an entire school of thought, if you will, that is now taking shape worldwide, with people who are offering training and coming in and assessing organizations and helping them to achieve this type of vision, right?
Dalton: Right. Well, you know, consultants, especially management consultants, have, for years, been talking about leadership reengineering and reengineering the organization. If you’re reading anything from Peter Drucker or any of those guys, they’ve been talking about it for years. And I remember, the decades I was with Ernst & Young, years ago, we always talked about this and we always did engagements, working with customers, to help improve leadership performance. What we didn’t have is a model that describes how to do it. We sat down with leaders and we said, “Well, who do you wanna be?” and, “I’m a smart guy. Let me help you.”
In a lot of ways, we need the same types of models and assessment and training that we’ve been championing for lower-level teams—Scrum certification, for instance, SAFe certification, DevOps cert and training. These things are considered normal coursework and certifications for the average worker now. We don’t have anything similar for leadership, and that’s what this model is all about, is giving leaders a chance to really learn and have a how-to model for how to improve performance and to get their whole organization certified so that they can be known as a really progressive Agile organization.
Shimel: And we spoke off mic, Jeff—you know I’m one of the co-founders of the DevOps Institute—so I have more than a little bit of experience and insight into what it takes to have sort of a worldwide network of people who are offering training, education, assessments, based upon, you wanna call it, “curriculum” or “knowledge,” that you’ve sorta codified, if you will. That’s a big job, right? It’s more than just Jeff Dalton.
Dalton: Right.
Shimel: And so share with us, if you can, a little bit, what’s the organization like?
Dalton: Sure. Well, we have a team. This didn’t start from scratch. I own another company called Broadsword that’s been around for almost 20 years and we’ve been reasonably successful in the performance improvement market. We work with various models, including Agile frameworks but also CMMI and ISO and PMBOK and Scrum and XP and SAFe. And we work with all of those models and we work with companies—largely, federal government contractors of pretty good size—so we have a lot of experience working with Fortune 500 companies all over the world. We have customers in China and Hong Kong and India and Japan and the US and then some in Europe and South America. We’ve been doing this pretty successfully for about 20 years and we’ve built a large network of CEOs and leaders, especially CIOs and CTOs, of organizations all over the world. And so that’s where we started, and so Broadsword has 15 people that have been focusing on other models and other training, by other organizations, for years.
And so what happened is is we were doing some assessments of couple of really large companies, two years ago, and we realized that the real impediment was this whole notion of vertical traceability, we call it, or vertical expansion of agility from teams up to senior management. And we started noting that with a lot of our clients. And so we said, “There’s something needed here. The industry really needs help with this, so let’s create a model that we can use with our clients.” Then we started getting calls from other companies, saying, “Can we use your model?” and other consultants around the world, and so we started—so it started organically, this network of a couple of hundred CEOs and CTOs and CIOs, which is where we came up with the name of the organization—“CXO.”
And so it really happened organically because of demand, so what we did is we shifted about half of those folks over to the organization to work on that and we hired a few folks. We have a chief operating officer; we have a CTO; we have a partner manager; we have model developers. So we have a team of folks that are really dedicated to this, to make it work, and we’ve outsourced things like marketing and bookkeeping and all that kind of stuff, so we can focus on the important things. But it’s a group of really senior, very experienced people, so we’re really pushing to try to make it happen.
Shimel: Yep. Hey, Jeff, we’re starting to run short on time, so I wanna start putting a bow around some of these things.
Dalton: Sure, yeah.
Shimel: First of all, people listening out there—and our audience is pretty diverse, worldwide, but can you give me either the one big reason, or the top three reasons, why AgileCxO is something they really need to take a look at?
Dalton: Sure. Well, the biggest reason is that agility and self-organization are unavoidable—they’re coming—and it has nothing to do with Agile. Interestingly, Agile and DevOps are a reaction to a worldwide trend. If you take a look at the Gallup study that’s done every year on people’s faith in leadership and institutions, what clearly is being defined in their study—and it’s a worldwide study—is that people are losing faith in traditional leadership. They’re losing faith in the kind of leadership that Harvard and Stanford are pumping out every day; they’re more interested in self-determination and self-organization.
This is happening in banking, education, software development—the military has even suffered from this or if “suffering” is the right word. All kinds of industries, universally, are moving, more and more and faster and faster, towards this notion of self-determination and self-organization. It’s a worldwide trend. And you see a lot of chaos in the world and that’s really what it’s about—it’s about a massive upheaval in the traditional norms of leadership.
And so it’s inevitable that, if you wanna maintain young performers that are of high quality and you wanna have a successful organization long term, that you’re gonna need to adopt Agile culture, top to bottom, in your organization. So you’re gonna have to completely reengineer the way you run your companies, or else you’re just not gonna be able to attract talented workers. So that’s just inevitable. The data tells us that that’s coming, so that’d be the number one reason to look at this.
The second reason is that leaders are really struggling with understanding what Agile means, what self-organization means and how to actually achieve it. And they’re getting a lot of pushback from the lower levels of their organization to be more Agile, but, if you’ve ever worked on an Agile or a DevOps team, you know that, the further upstream you push, the harder the swimming gets. There’s a reason for that—we call that an “organizational type mismatch,” where I’ve got a command-and-control infrastructure, from CEO down to basically supervisor level, in an organization, and then I’ve got all these people saying, “I wanna self-organize and be more Agile.”
So that clash of cultures is extremely energy-dependent—in other words, burns a lot of energy in your company—to the point that your costs are overcoming your profits. So that would be the second reason to do it, is it’s a how-to guide for how to avoid that cultural, organizational type mismatch.
And, finally, I think the third reason is that it helps employees be a lot happier, and happy employees are more productive and happy employees stick around longer and happy employees, team members, are happier to work there and create less friction, less resistance. So it’s good for everybody. So all good reasons to check out the book, to check out AgileCxO. And if you are a consulting firm or a company that really wants to help companies achieve these three goals, become a partner and join us and join us on our mission. We’d love to have you.
Shimel: Very cool. Jeff, last part—and it really segues off what you just said—where can people get more information?
Dalton: Well, two places that I would recommend you do that. One, you can buy the book on discount at Amazon, just “Great Big Agile”—go to amazon.com. You can also buy it from any other book retailer, if you like Barnes & Noble better, or from Apress—apress.com is who distributes it for the publisher—but Amazon is probably everybody’s go-to for where to get the book, so I’d definitely take a look and read at that.
And then agilecxo.org. If you go to agilecxo.org, you’ve gonna have at your fingertips samples of the model, lists of the training, videos to watch. We do our own podcast, similar to yours, Alan—the Agile Leadership Podcast. And what we do there is we interview CIOs and CTOs of state and government, primarily, around the country, so we’ve got Texas and Kentucky and Florida and Michigan and Wisconsin and CIOs from really large, 2,000-, 3,000-person IT organizations that are trying to adopt Agile. And we get their perspective and the things they’re struggling with at the Agile Leadership Podcast. So all that’s available at agilecxo.org and feel free to stop by.
Shimel: Excellent. Jeff, we’re about out of time. First of all, thank you very much for sharing with us today the insights and more about AgileCxO. Continued success with it. We’ll watch it go and maybe we have you back on the show, couple months, and see where things are.
Dalton: Thanks. I would appreciate that. And, while we’re talking about that, Alan, we’d love to have you on our “Agile Leadership Podcast.”
Shimel: Any time. Just let me know when and a dial-in or log-on and I’m there. Hey, stay warm down there.
Dalton: I’m doing my best. I think I may have one degree on you down here.
Shimel: Yeah, maybe. But it’ll warm up soon enough and I’ll have to get—you know, I like _____—usually, I go to Islamorada fishing.
Dalton: Right. Yeah.
Shimel: Key West partying and Marathon somewhere in between, so—
Dalton: _____ not gonna lie, we do a lot of fishing around here.
Shimel: Oh, I’m sure you do; it’s good fishing. Anyway, Jeff Dalton, the AgileCxO organization and author, thanks for being our guest here today on DevOps Chat. And this is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Have a great day, everyone. We’ll catch you soon on the next DevOps Chat.
— Alan Shimel
Specifically, Chef said it has achieved FIPS compliance along with providing an implementation of STIG profiles for RHEL 7 and Windows Server 2016 in Chef InSpec and achieving a (CIS) certification for Amazon Web Services (AWS) Foundations Benchmarks Level 1 and 2 in Chef Automate. Chef claimed it is the first vendor to achieve CIS certification across AWS, Microsoft Azure and Google Cloud Platform.
Unveiled at the