S5 E6 - Jim Highsmith – Navigating the Past to Shape the Future

In this episode, I have a fascinating conversation with Jim Highsmith. We dive into Jim’s six-decade career in software development, his role in the Agile movement, and how his early influences continue to shape his thinking on digital transformation today. Jim shares stories from the punch card era to the Agile Manifesto, offering insight into the evolution of our industry.

We begin by exploring Jim's early work at Exxon, debugging code with hexadecimal printouts, and his eventual pivot into structured methods and adaptive development showing a career built on embracing risk, fostering change, and learning through experience.

Jim recounts the serendipitous path that led him to the Agile Manifesto in 2001, where he collaborated with figures like Kent Beck and Martin Fowler. He shares how his early thinking around adaptive methodologies aligned with what became known as Agile, even before the term existed. Throughout, Jim highlights how technological shifts, especially the rise of the internet, fundamentally altered software's purpose requiring new development paradigms.

In reflecting on Agile’s legacy, Jim contrasts optimization (à la Deming’s statistical process control) with adaptation (rooted in people, learning, and responsiveness). He emphasizes the importance of context in applying any methodology, whether Agile, Lean, or DevOps, and cautions against rigid orthodoxy in favor of flexible thinking. The conversation also touches on Deming’s influence, the missed opportunity for Agile and DevOps convergence, and Jim’s role in fostering integration between the Agile Alliance and the Project Management Institute (PMI).

Looking to the future, Jim sees AI as a transformation on the scale of the internet, requiring organizations to adopt adaptive mindsets or risk irrelevance. He warns that those who fail at Agile will likely fail at AI if they don’t build adaptive learning into their culture. He advocates for reimagining agility not as a fixed set of practices, but as a living, philosophical approach responsive to continual change.

Transcript:

John Willis: Hey, it is John Willis again. The profound podcast. I guess, you know, most people at this point have it, it started out as a Deming thing. Now it's sort of everything, but we sometimes try to squeeze Deming in when possible, but certainly it can be about any topic. I've got a great guest this morning. A fair amount of you probably heard of him because he's. You know, he's, he's got an incredible career. You know, and, and not to say my career is incredible. It's been incredible for me. But, but it's so interesting how we sort of knew each other, you know, sort of online presence, but it was a dialogue we had on a LinkedIn, somebody else's post I think, where we just started chatting and we realized how similar our our career paths were.

And I think it was just a lot of fun to talk through some of our experiences and then like work us way up for. So I guess I'll start with Jim. Why don't you go ahead and introduce [00:01:00] yourself.

Jim Highsmith: Okay, Don. Thanks for inviting me. I sounds like it's gonna be an interesting interview. The last book I wrote called Wild Wild West Agile was sort of a 60 year history of agile development and software development in general.

And at the end of that book, one of the things I talked about was the fact that if you really believe in collaboration, and I do. Then I think knowing a little bit about who I am as opposed to what I've done is important. And so I've rewritten my bio to, to show that. So I, I've built myself as a adventurer, a catalyst, and a storyteller And adventurer.

Is that like to do kind of exciting, risky things? Both outdoors things like rock climbing. Although I don't do any of that anymore and adventures in business, I've made a couple of pivoting pivotal decisions over my career. [00:02:00] The second one is Catalyst. I have, I have an undergraduate degree, degree in electrical engineering and a master's degree in business, and I've always been a catalyst between those two functional areas.

And thirdly, storytelling. I really started, I. Even more and more of the last few years writing in a storytelling mode as opposed to just a narrative mode, because I think that helps get things across better. So that's kind of a little bit about who I am and we can kind of get into the history in terms of things that I've done.

John Willis: Yeah, no, I think, you know, it's funny, I was, as you were talking about that, like we're both sort around the same age, but I'm sure you've gotten this over the years. I think there's something, again, as I say, I'm like you and I say you're interesting. I'm gonna temper it with like, I kind of am not bragging about myself being interesting.

So somewhere in the middle there. But, but I think what, what is interesting about both of us in the lowercase eye for [00:03:00] me is that, you know, I, I, I have these young kids come up to me periodical times and say, oh, I love that presentation. I. And you know, I read in your bio that you literally, it started out on IBM mainframes writing in assemble code, and it was like my grandfather did that.

Then they'll talk about their father is still doing something they've been doing for 50 years, you know, and like, they're like sort of amazed that I could be in my sixties and, and like talking about now AI or before that, like cloud native or before that. Right. So. I'm sure you get a little of that too, if people are like, and I, I guess the meta point is I think there's something interesting in, in people like us who we can't sit still.

Like we're in our sixties and we're still waking up in the morning and saying, oh, what's this cool thing? The adventure in you, you know that I think it's I think that that's another reason why I was sort of attracted to your background, you know?

Jim Highsmith: Yeah. And I'm considerably past 60.

John Willis: There you go. All right.

I was trying to be nice. I'm [00:04:00] 65, so I'm like, maybe halfway to you. I don't know. Yeah, but no, it, it is sort of fun. You know, the other thing I like I want to learn more about you, but like, when I, I, I sold the company to Docker and I was like the oldest person at Docker by at least 15 or 20 years, you know?

Yeah. That was like fun to brag about, right? Like, so anyway.

It's sort of fun to meet a kindred soul who like the curiosity. And I love the story. I love storytelling too. I don't know where I picked that up along the way, but, but it really just becomes such an effective way to, to explain things to people, to contextualize technology and you know, from, you know, for the responses we get people enjoy learning that way.

Jim Highsmith: Yeah. It makes it interesting.

John Willis: Yeah. Yeah. So let's go back in time. It looks like you know, like you said, you're a little older than me, but we almost crossed paths at Exxon.

So it sounds like you started out at Exxon. I, I, I got there like late [00:05:00] seventies. And the exploration, you know, doing the technology and it and mainframe stuff for the exploration. Boom, boom.

Jim Highsmith: Yeah. I was in the refining department from like 70 to 76 and I had, I got that job out of graduate school and I had a couple jobs previously, which just more engineering jobs before I got my master's degree in business.

And I went to Exxon and this literally was the day. IBM mainframe and, you know, card input, punch card input, and you wait a, you wait a half a day for your output to come. The tech stack was, operating system cobalt compiler. That was it. That was it. That was the tech stack. And. Debugging tools were, you got a core dump of everything that was in core and you had to trace it and be able to read hexadecimal to see where [00:06:00] things had gone wrong.

So it pre printed primitive?

No, I remember they were yellow cards back then. Right. Where it had all the operating system and you knew what every op code was and,

John Willis: right.

Yeah. And, and, I mean, it was it was, you know, I think the, the punch card thing, I, I was a little bit fortunate by the time I got there.

It was only, I was like a cis admin helper when I first got to Exxon. And, and there was only one guy left that still submitted all his jobs through punch cards, but they were coffee stained. And so he had the JCL, if you remember, was all this, and those cards were like his, like. You know, like don't, but they were dirty, they were bent and they would always like not go through the card reader.

So there

Jim Highsmith: was a story about in the mid seventies about a guy who was in charge of a flight avionic software, one of the airplanes. And he had a engineer come in one day and you know, a plane waits really important, right? And so the engineer asked him, how much does your software [00:07:00] weigh? And the guy said, well, it doesn't weigh anything.

He said $13 million and it doesn't weigh anything.

John Willis: Oh, that's hilarious. Oh, that's great. So he

Jim Highsmith: went, he went off, came back the next day with a box full of cards. A handful of cards. Yeah. And he says, these cards are your software, right? That's right. And the guy said, yeah, representative. He said, so I, I weigh a box of cards, I have it way to your software.

John Willis: There you go. Oh, that's brilliant. Oh, that's a great story. Alright, so you, you sort of moved on and somewhere between sort of Exxon and just doing technology. You wound up being a big part of Agile, right? I guess you were part of the Agile manifesto or like Right. How do we get from sort of an electrical engineer, maybe a business degree Exxon, just doing sort of probably all the technology things we were both similarly doing to somehow being a pioneer in the Agile space?

Jim Highsmith: Well, it really got started in the early 1980s. I was a, I was a [00:08:00] manager of a systems development group in a electric utility company, and we brought in some people to teach us some new structured methods at that point. And I ended up going to work for one of these startup companies in structured methods as a, interestingly enough, the VP of sales and marketing because I had a lot of software engineering background and, that really got me started in, into the sort of training consulting side of the business. And so all during the eighties I did sort of what I call monumental methodologies and which took the structured methods, which by and large were good practices and put this great big methodology umbrella around them.

And you know, what happened in terms of slowing things down. So during the nineties, I sort of evolved from kind of real structured stuff to sort of rapid development [00:09:00] to what I called adaptive development, which eventually led me to Kent Beck, Martin Fowler, and a few other people that involved me in the Agile Manifesto meeting.

So I, in fact, I just published on LinkedIn. Read out three articles that I wrote in 19 92, 19 94 and 1997. That sort of showed the evolution of my thought process to get to where it was more agile.

John Willis: Fantastic. So how, what is it, what's, what's like the, the journey because you know, like it was, you know, I come into this from, a different trajectory. Like, you know, I was sort of an ops person and you know, this sort of pre DevOps, you sort of lived most of your life in this infrastructure and operations and. I'd hear, you know, friends of mine talk about Agile, and I'd be like, yeah, I'll get to that tomorrow. You know, and, and then, you know, by the time I, I sort of got fully thrown into the, the pre early, what was about to become DevOps and then DevOps days, you know, I, I started learning a lot more and I [00:10:00] thought, well, what a monumental event did the Agile manifesto and, you know, and so, I guess the, the question is like, how, how do you get pulled into, we're working with those guys and like, Hey, show up here and you know, at this place and let's talk about something. So part A, part B, part A is like, how do you sort of get to be at, at a really cool time, a real place at a cool time? And then two, did you realize the magnitude of what you guys would doing during that?

Well,

Jim Highsmith: obviously we didn't recognize the magnitude and I, as in most things like this, I, I got involved accidentally. So I met Martin Fowler in New Zealand. The first time we met him. He and I were both speaking at a conference in, in New Zealand. And so he, he said he didn't have much hope for my presentation.

He thought it would be another monumental methodology presentation but it turned out not to be. And so he really liked what I had to say. He was doing work with Kent Beck, so he [00:11:00]introduced me to Kent Beck. Sometime in late 1999, Kent and I exchanged manuscripts and realized we were both kind of going down the same path, a parallel path.

And so I hadn't really gotten in with the OO group, but Martin and Kent and some other people, were really in the object oriented crowd. And that's where, where I kind of came into that. I started going to XP conferences and I spoke at a couple of XP conferences and then the Agile manifesto meeting happened.

John Willis: That's, that sounds pretty incredible. So like you said, you didn't, you couldn't comprehend. It is sort of like, you know, I mean, I, I I, I, I put this in a little lower category, but I, you know, I was at the first DevOps dayss in t and, and it was only about 40 or 50 of us, and. Like, I knew it was important, but I didn't realize what it was gonna look like 10 years later, you know what I mean?

In other words, in terms of how it was gonna change industries and like, it's one of those things, it is sort of similar to, to the [00:12:00] Docker thing, right? I knew Docker when I first sort of got access to the repo before it was open source that it was, it was going to be big, but I didn't realize how big it was.

And so I wonder that kind of experience for you. I think we didn't

Jim Highsmith: realize how big it was gonna be. On reflecting back, one of the things I found or decided was that there was some, some forces at play that really sparked the agile movement.

John Willis: Okay.

Jim Highsmith: And everybody would say it was, the internet was one of those things.

But I think the thing that people miss a lot about the internet and as it grew during the late 1990s is it changed the whole focus of software development from developing internal systems from our company. To developing external systems for, for customers, end users and that, and that was a monumental change that drove different ways of developing software because you just couldn't develop software [00:13:00] fast enough using traditional methods for the internet era.

And so what you saw a lot of companies back then is you saw 'em splitting and they would have an internet, internet systems group and a legacy systems group. The problem was that those two groups battled each other and the legacy system group would say, oh, those are legacy system group. They're just like dinosaurs.

And the legacy systems group would say all those internet people, they're just, they're just built toy systems. Yeah. Yeah. And, and so, so that created some schism within a lot of IT organizations.

John Willis: I guess at some point open source wedges its way into this too. Right? Right. The well a lot of things changed in, you know, in like 19 97, 19 98.

Jim Highsmith: Who could have imagined what would be going on in the 2009, 2010 era? You know, we had. Big data, and you had [00:14:00] social media and you had digital organizations, and you had Uber and Netflix. It was just a whole new era.

John Willis: Right, right, right. Yeah. And then all sort of built on that. And then, then you, so, I think, you know, we, we talked about, like, I, I thought, I think, you know, I sort of exaggerate, but like normally if I'm talking to somebody within about 10 minutes, I'll ask them.

Did you work at Sun Microsystems? Because there's, there's something about the people. It, it, you know, like I, I guess you know, there are people way older us maybe that like, had that experience with people from Bell, the old Bell Labs, right? Like there's like, there was some DNA in Bell Labs and then there seemed to be like a DNA and that window. 

In the nineties the people worked at Sun. I, I, and I think ThoughtWorks has that same like, like, and like more for me. I got to know people. You know, ThoughtWorks I always said was one of the best stewards of the early DevOps days. 'cause they [00:15:00] always, there were three companies that sponsored DevOps days unconditionally.

They never asked for anything. There were no booths. They just did it because they believed in DevOps and it was ThoughtWorks, puppet and chef. And those were the three companies, almost unconditionally sponsored everyone. And I got to meet a fair, like just humble. And you a fair amount of people through the DevOps agency, and I realized, wow, there is something going on in that place that is like different than any other place.

So

Jim Highsmith: yeah, it was a real different organization. You know, they, I was, I. Kind of recruited in, in 2005 to go to ThoughtWorks, and it didn't work out then. But in 2010, I did go to work for ThoughtWorks and was there for 10 years. And I, I would never have thought I was gonna be there that long. But I kept going to my bosses, my managers, and saying, I'm ready to retire.

And they would say, don't, don't retire. Well have to cut your hours by 50%.

John Willis: Yeah, no, they just seem to have all the cylinders. I mean, they were up, you know, I think the first time I [00:16:00] heard about value stream mapping was, it was even before I, I sort of bought the book, you know, the canonical book by Mark Roth learning to see, I, I literally had read an article or something from somebody from ThoughtWorks to talk about how to use value stream mapping and consulting practices.

And so even that's what started me down. Lean path. So yeah, there, there was just so much great stuff that, you know, that came outta there. And again,

Jim Highsmith: you, you talked about sun. I really was into more of, of the business oriented computing, so I didn't, I didn't really get involved much in Silicon Valley types of things, although I had some clients out there, but I didn't, I wasn't a Silicon Valley insider at all. 

Just like I wasn't involved much in engineering and scientific computing, so what I was involved in was, was basically business computing for, for, for most of my career.

John Willis: Yeah. I think the [00:17:00] thing about Sun is I think about what, what was the triggers that got me to say, how did you work with Sun? Was they understood the people who worked there.

Literally understood conversion infrastructure like back in the day, right? Like they were sort of experts in network storage compute, right? And so like in a conversation with them, like particularly in you know, around 2000 8, 0 9 or 10, which is before anybody was really talking about sort of package converged infrastructure.

They seem to ha think that way. And I, and I, and then you look at their history of what they were trying to produce back then. It's you know, that, that there, there was something about, like, you, you, you normally, like in 2010, it was rare to find somebody who was a network guru, you know sort of a, a compute, you know, virtual system guru.

The storage guru. Right? Those are usually siloed. And I, I always thought that they seemed to have a DNA where that was all, there were no [00:18:00] boundaries for those type of things. So as an I and O guy, that was fascinating to me. So, but so I guess that we get into now the hard questions. So now, you know, you've seen the you've had the experience.

I mean, one of the things I, I think about doing this for 40, 45 years or whatever is. You can always look at new patterns and map them to old patterns, right? Like, I think that's one of the things that sort of make, you know, sort of experience in any field, but certainly in this field, like where you look at something, it's say, oh yeah, I mean, that, that's different, but really it's not too different.

Right? And, and you know, and, and so. I think like, I'd like to hear your perspective of like, you know, like, I, I, my, my last book right was about Dr. Deming and I do wanna talk about Dr. Deming as well. But, but, but I was trying to like, you know, I did this Deming to DevOps, right? And a lot of it was like, how did we get to lean, right?

We kind of know that comes from Toyota [00:19:00] generally. And then, you know, where do we get from lean to Agile? Where's that sort of parallelism or, or linear. Then we definitely get to sort of something we call DevOps. And I was just wondering like how do you see that sort of pathway in from your experience?

Like, you know, going from like sort of a pre lean to a lean agile and certainly your experience is probably more from a software development business standpoint. Yeah.

Jim Highsmith: You're, you're. About bringing some history in as to how things happened before, and I think that's one of the things I've tried to do with my writing is bring some historical perspective in. 

Just, just to give you a, a very simple example the no code, low code movement, which had some real benefits and some real challenges. It was sort of the same way as in the early nineties people started using spreadsheets. And the spreadsheets were being used by non [00:20:00] IT people, and I actually knew of a situation where they didn't know how to test it well enough.

They put the system in place in a bank to manage mortgages and managed to lose money on every mortgage because they didn't test their spreadsheet correctly. And I sort of see some of the same issues with no-code, low-code. And I wrote a little bit about that, but that's just one, one incidence. And I, I think going back in history is a, is a good way to sort of see how we got there because I think the, the lean movement was sort of in parallel with the agile movement up until the mid two thousands when they sort of agile assume some of the lean stuff or lean su subsumes some of the Agile stuff.

And I, I think more and more people were to cutting themselves as being lean and agile. And the, then the, you know, I was, I knew Jess during this period of [00:21:00] time and was familiar with a new book on DevOps. Right? And so DevOps in a way, and I haven't followed it closely. Not, not like you drew out of the agile movement.

In some ways, and there were other shoots that, and that came in there,

John Willis: no doubt about, that's all.

Jim Highsmith: But then it seems to me, and I, again, this is sort of from afar, that the agile communities and the DevOps communities sort of bifurcated and went their own ways. And I, and I always thought, but that was an.

That was too bad.

John Willis: Yeah, no you're, you're spot on because one of the things that most people don't realize, so I was, you know, people call me one of the founders of DevOps. I, again, I was at the first DevOps event in Ghent me and Damon Edwards, mark Kinkle and inter cliche for ran the first DevOps days in the us.

I got to meet Jean Kim. We started working on the DevOps handbook, so I, I've been a big part of this narrative, but in the early, early days of [00:22:00] DevOps, we'd go into companies. The Agile people would literally be like, they, they'd be angry with us. They wouldn't want anything to do with us, and they were threatened by DevOps.

So today people look at, oh, agile DevOps. Yeah. In fact, you go into large companies now, like it's really the same thing in the, from the corporate perspective, they don't. Very few companies you, you I talked to today. Talk about, well, the agile teams over here and the, I mean, they, they've sort of fused it into product.

Well, that's the

Jim Highsmith: whole philosophy behind DevOp DevOps.

John Willis: Right, exactly. But in own case, the agile people, which again, what we were just sitting in on was, in fact, I will argue that most of us, not all of us, but most of us didn't even know we were inheriting agile and lean principles in this like shiny new thing we thought we were creating.

I mean, it all made sense so we didn't like question it. Right? Like yeah, why should dev and ops be siloed and not talk to each other? [00:23:00] Why, like all those things, you know? And as even like, I, I would say that even sort of Gene Kim who's, you know, considered the, the, the poster child for enterprise DevOps rightfully so. 

You know, we did a book together called Beyond the Phoenix Project, and we tried, we literally explored. Where do we get, what did Lean contribute to this? What did Agile contribute? We also looked at Deming and and Goldratt, but. Yeah, I think in the early days of DevOps, I think a lot of people in the Dallas movement weren't even aware where we were inheriting all these principles. 

As we learned like almost all of 'em came from lean and agile. And, and then I think the other interesting thing is that we were, in my opinion, the early days of going into enterprise to try to, you know, somebody in a corporation say, we need to bring in these DevOps guys. This is the right way to do things.

And we would literally get shunned by the agile people. So.

Jim Highsmith: That's interesting. One of the things that experiences I had, and this was [00:24:00]in the early 1990s, and I went into a bank to, to do a agile project and it took about three months to come up with the final system. And so then we took it over to OPS and said, would you, would you put this into operation for us?

And they said, yes, that'll take six months.

And so that, that. Period. You know, that six months was, was a long time. When you're doing well, it's a short, it's a short time. If you're doing a two year project, it's a long time if you're doing a three month project.

John Willis: Yeah, no. And

Jim Highsmith: you know, Ken Begg talked about continuous integration way before the DevOps movement started.

And, and so I think, I think the two fit together and it,

John Willis: it, oh. J Humble, Dan North and Chris Reed will all work there at or I don't know if they overlapped with you. In 2006, did a presentation at an agile conference, which [00:25:00]literally showed what we typically even today called the DevOps pipeline.

You know, the sort of green, green, red, go back, green, green, green, red, go back, green, green, green, red. Green, red, you know, that like that, like that, that image is still burned out there on most people's screens and usually, you know, shows up, has showed up quite often in Dev DevOps presentations. And that was 2006.

And so, I mean, the term DevOps wasn't even coined till 2009. You know, by Patrick Debar when he ran the first DevOps dayss in Gent. So, yeah. Definitely, again, going back to the ThoughtWorks influences here you know, it was, and then obviously continuous delivery predates, DevOps, you know, with sort of j and Jazz's book on cous delivery and just all the work the ThoughtWorks was doing on in this space, you know, so so I, [00:26:00] I guess the other thing I wanna ask is I think our conversation led us to this.

Because we were sort of talking about some post about Deming. Did I get that right? And, and then maybe we just, right. And so, so then the question begs like, so the, the question I normally ask people or I have asked all the time is like, why you, why Deming? Why you and Deming? What made you think about Deming?

Why, why did he become part of your, sort of, your, your mind share about what we do? And, and I guess why is he important? So I noticed a lot of whys, but,

Jim Highsmith: well, I was aware of doing for quite a long time and mostly about manufacturing and statistical quality control and what he contributed in in that area.

And one of the things that I pulled out of that was that, again, the two main topics that I talk about during the nineties was the difference between [00:27:00] adaptation and optimization. Okay. And that I put Deming in the optimization camp. And that some of the things that they used, like statistical quality control and control parameters for manufacturing ensured that, that you had a repeatable process.

And then for the adaptation world. Repeatable process was not something that you could do. It wasn't a repeatable process. It was a, it was a reliable process because it included a lot about people and their interactions and collaboration, problem solving. And so I always wanted to use the different words for the optimization side and the adaptation side.

And I think a lot of places we've gotten split. And so the Agile community might say down with [00:28:00] optimization and the optimization community, or I say down with agile, but it really, for any given situation, any, any given problem, there's a combination that's the right combination for a particular context.

And that's the thing that I think we've lost is the ability to take stuff from different perspectives and put 'em together, given the context in which they'll work.

John Willis: But you know, that's a human condition too, right? Because I mean, what, like, I got into demming late, right? I, I, you know, like I said, I, I was sort of, my career was sort of pigeonholed by being an infrastructure operations, which I'm not getting.

I love that. You know, I love that I was an I and o person most of my career, right? And, but, but like, it was DevOps that sort of broke me out of like, okay. Like, I'm gonna have to learn a little more about this lean stuff and this agile stuff. Right? And, and I, and what one of the things I found, which is incredibly interesting, and then somewhere along the way, you know, I, I've told the story hundreds of times about how like, I, I backdoored my way [00:29:00] into Deming through Genes Phoenix Project, which was driven mostly by Goldratt.

And then, you know, a friend of mine sort of. Advised me that if you're gonna understand, go right, you need to go back to Deming. Right. And that, that sort of changed my life. Right. But what was interesting is I went to certain lean communities, it it as if they, that Deming never existed. Right. Or that you know, I've even had some people as, as far out as in front of the lean communities say that Deming had nothing to do with Toyota.

Like, which is just nonsense. I've proven that over and over. And so, and then in the Agile community. There was some Deming stemming skeletons, but first of off, if you didn't have agile and lean, like you discussed talking to us early on, DevOps became a third silo. And I, I couldn't find anybody that was talking about unification of all these principles and other principles like xp, all these things, right?

But, but [00:30:00] certainly. Like for those people to understand Deming, I, I think there was an umbrella that was just missed, and I'm sitting here coming into this as a newcomer to all of it, the old Deming community. Even today, people who read my Deming book, like they're old school Deming and they know really nothing about lean, nothing about it.

Now they're all manufacture, they're mostly from a manufacturing perspective, but it's just, it was odd to me that we had all these like silos. They were all overlapping and nobody was taking the effort to, to sort of unify a discussion. And to me, I'm, you know, I'm sort of a sycophant for Deming, but, but like, you, like, like Deming seemed like the logical choice to create the umbrella, but even if you didn't opt into that, it just seemed like everybody was in, in their lane.

And like, it was very, it was almost impossible to get these people outta Atlanta. Well.

Jim Highsmith: In the management community. There's not much said about Peter Drucker anymore. Yeah, yeah. Tell you, give us another, but [00:31:00] Peter Drucker created or founded some of those principles that are still in use today. Mm-hmm.

John Willis: And you can, like, I, you know, I, I sort of did some of this lineage, like, you know, Drucker was a student of Peter Senge.

You know, Peter Senge was heavily influenced by Deming. Right. So, you know, there's always an argument that a Deming I can make it all goes back to Deming, but, but you, I'll, I'll be sort of a little cautious on that, but, so Deming was a big part of your, of your toolbox, I guess, over the years. Right?

Jim Highsmith: I, I wouldn't say it's a big part, but it was definitely a part.

John Willis: Okay. Fair enough. That's very good. So it, this gets us into like, so, you know, like you've gone through all these phases. We got the Agile, we got the lean, we got the DevOps. And, and again, you said you haven't been sort of diving deep into DevOps, but it's, it's sort of all around you, right? These principles as you work and help managers figure stuff out.

And, you know, we've seen some incredible technology shifts, right? Like, you know yeah, I think sort of like your point about, there was [00:32:00] some point in the beginning of this. This millennia where like things changed enough where people, you know, which sort of promoted the idea of agile, like people were sort of creating services differently, right?

And there was some, a lot of conditions to do that. And then we had sort of the cloud, right? And so those were big shifts and like you and I had to sort of wade through those became like we put our perspectives in what they meant for what we do. We had to be able to talk intelligently about these things to leaders.

But we're in a technology shift now that is unlike anything I've seen in my 45 years. So, hate it. Love it. Don't believe it. Believe it doesn't matter. This is the use, you know, a really terrible sort of metaphor. The train has left the station ai. I mean, so like what, what are just general thoughts about like, from your historical perspective to like, what's going on [00:33:00] now?

How do you advise leaders and, and I'd like so much not like what to choose, what not to choose, but like how do we, how does somebody who's played a role in this industry in some significant changes and things, how do you yourself. Think about and then how, like I'm sure you have clients now that are asking you these hard questions about, Jim, what do I do here?

What's going on?

Jim Highsmith: Well, to me, and I've been through a couple of high change type situations at the beginning of the internet was was definitely one of those changes. And it seems like we're always in the speed up curve about these technologies. But from what I can gather, and I've done quite a bit of reading on this in a lot of different places, is that this is truly a different situation and it because of two things, because of the breadth [00:34:00] of impact of ai.

So you, over here, you've got physicists winning a Nobel Prize assisted by ai. And you've got AI embedded in business processes. And, and so I think that it's inevitable, and I don't know how fast some of these things are gonna come along, but I've written two things recently, one of which is if you fail at Agile, you'll fail at ai.

And what I meant there was, if you don't have an agile adaptive mindset that you've, that you, that you've grown during the Agile. Movement, then you won't, you won't have that to apply to ai. You need an adaptive learning mindset in order to survive in ai. The other thing that I wrote about was the fact that you have some time, but you don't have a choice, and that's as an individual or a corporation or an organization, you have a little more time than you think you do.[00:35:00]

But you better get started because it's gonna overwhelm you if you don't.

John Willis: Yeah, I've heard the analogy is like, you know, it's moved from, you know, 10 miles an hour to a hundred miles an hour. If you wait too long, it'll be a thousand miles an hour. If you wait any longer, you won't be able to catch the train 'cause it's going 10,000 miles an hour.

And I.

Jim Highsmith: Historical perspective I like to bring to this is when I was in engineering school, we designed circuits with transistors that are about as big as the end of your finger. Today. The, the new Nvidia Blackwell chip has, I forget, like 5 billion transistors on it. If you were to take those transistors as 5 billion transistors.

And, and they were the same size as the ones I dealt with back in the sixties. It would, it would fill up 10 square miles

for

each chip.

John Willis: Wow. Yeah. Yeah. And

Jim Highsmith: so from a, from a [00:36:00] hardware standpoint, that's where we've gotten to. One of the things that I've been working on. It was sort of a damned if you do, damned if you know, kind of situation, which is, I think in order to meet the challenges of not only ai but all the other technologies that are coming along in terms of sensors, in terms of visual visualizations biotech, that

we've gotta have a. A response to some of those that is more a adaptive in organizations, and so we need to figure out how to speed up that adaptation. But we've proved in the past that we can't speed it up, that it's a slow process. And so it's sort of like the immovable object meets the unstoppable force.

We, we need to move faster, but we haven't pro, we haven't shown ourselves how to do that. And so that's one of the things I'm looking at from a management [00:37:00] perspective is how do we accelerate organization, organization change when we've been so bad at it in the past?

John Willis: Yeah, no, I mean it's, you're spot on, right?

Like, I mean the sort of adaptive capacity is, you know what I think you know, the evolution of like if there is an evolution of lean, agile, DevOps, right? I think. Most people would understand this is about sort of adaptive capacity. How well, what's your sort of capacity to do whatever, improve, change, whatever.

How adaptive it is, is the fluency of how well you're going to perform, right? Which we could call it agile, we just call it organizational behavior in general, and I think you're spot on. The reason why I think so resonates with me, I hadn't really described it in a form of adaptive capacity, which is clear.

Like you said, if you're gonna fail at Agile, if you're failing at Agile, you're gonna fail at ai. And I love that. But I had A-A-C-I-O, young CIO that I interviewed end of last year, and he talked about like, John, I'm not [00:38:00] worried about AI as an ROI, it's not what I'm focusing on. You know, he said, what I'm focusing on, I've got, you know, 25-year-old Java developers and I've got kids coming outta, you know, university with AI degrees.

What I need to do as an organization. Is to sort of you know, transformational thinking and innovation or, so I, what I need to do is get everybody on the same plane. In other words, my challenge now is this is the new innovation cycle. This is the new sort of innovation.

This is how we're sort of going to sort of talent. Okay. So, so talent and innovation transform transformational talent and innovation is what I have to scale in, in sort of I. In a, you know, sort of in a way that where everybody's sort of working. 'cause the problem with all these new technologies is if we don't scale it across the board, you know what happens over the years, right?

You have a new technology like [00:39:00] cloud. Well, group A is all in on cloud, right? Group D, lukewarm group C is, we'll never use it. Group D is all in on it. And guess what All those groups have to do is coexist.

So therefore it, it never works because leadership didn't take the sort of the trans, the talent and innovation transformation as the thing we had to do.

And I think, you know, when I think about this problem, and I think about you talking about adapt, you know, adaptability and is the key, I think it's up to leaders. You are gonna fail. If you have, if you, you know, let's just go through, there are people, there are sort of Luddites in companies right now that basically will like, we'll never use ai.

I don't care what the boss says, he's an idiot. You just can't use it. 'cause it doesn't. And then other, you heard the same thing about Agile. You heard the same thing about Yeah. But we hear it over and over and over and it's been the same sort of responses for every technology change that's ever happened in humankind.

Right. So. So I think, I think that [00:40:00] capacity is spot on. So well, you know, any any sort of parting wisdom, my friend or,

Jim Highsmith: or, well, one of the things I wanted to talk about a little bit was the integration of Project Management Institute in, in the edge of Alliance. Okay. Because that, I think that has some significant challenges and some significant.

Benefits to offer the community. And you talked a little bit earlier about somebody that helped pull together the DevOps community and the Agile community, and that didn't happen. I'd like to help pull the, as a, as my role as a catalyst, I'd like to help pull PMI and the Agile Alliance.

John Willis: Oh, okay. Yeah.

Yeah. Make that integration

Jim Highsmith: really work because I think, I think it gives to the Agile community an access to. Leaders that they haven't had before in math. And I think it brings to PMI, the [00:41:00] ideas behind agility and adaptedness, which they have already embraced in some of their new documentation or some of their new approaches.

And so one of the things that happens within the Agile community and between the Agile community and DevOps and or PMI is. We get stuck on old stories that are not true anymore. Right, right. You know, so we get stuck on the old stories that PMI is too structured, too prescriptive, and if you read some of their new stuff, that's not it at all.

Now does that say that everybody with MPMI toes that line? Of course not. But then nobody in the agile community does does that either. So last year. I was involved in a, in an initiative called the the Re-Imagining Agile. And what we were trying to do was to bring back some of the underlying philosophy of agility back into [00:42:00] the agile movement.

And I was talking last year to a guy who is the head of a group of innovation and ai. A theological school, which is kind of interesting to have that, that kind of group at a theological school. But who else to help us identify and define the ethical issues that we have in in ai. And one of the things he said during our conversation was that he has theological students who study people from history.

And they say what happens is that they learn about the proclamations that these theologians made, but they don't understand the thought process behind the proclamation. Right. And I think that's one of the things that several of us are trying to bring to fore in the re-imagining agile integration, is that idea of what's behind [00:43:00] the words.

In the Agile manifesto, they don't. You know, you don't have to interpret 'em Exactly. Interpret 'em from a perspective of what, what they really mean

John Willis: or, or the context of which they're in, which means that Right. What the agile, like if so there, the, those immutable principles of these ideas and what they mean.

What they mean fundamentally, that that like, they're sort of like in a physics, they're sort of scale free, in other words. Like they, right, they literally, these things are not affected about, like, was it 1980? Was it 1990? Was it 2010? Was it 2025? And I think you're spot on, right? That, that like, so what, what PMI, you know, I mean I grew up, we both grew up.

Being influenced of PMI. But you know what, you know, what did, what did the sort of the agileists and the sort of like that we, we needed not me, but just like DevOps, you know, in a sense I'd say that the Agile hostile, there were a lot of DevOps people that went in and just bad [00:44:00] mouth, like, you're doing agile, what are you outta here?

And like, I mean, I've been in conversations with people like PMI Oh no, don't let those guys come near us. You know, no Gantt charts, you know, like the poster, like Right. You know, so, but you're right. I mean the, the, the, you know, I, I'll just do a little segue here. I mean, I, I got involved with for a short stint, I worked at GE Capital and I was in a division that was Six Sigma Insane.

Six Sigma, right. I will tell you, and I won't argue with anybody who talks about how Evil Six Sigma is, because you know, like we can have that, we can have that discussion, but there were things in Six Sigma that were beautiful. Right. Really beautiful like stem from scientific method, you know, how you literally had to understand your process, that it was always a new, it was sort of a variant of, of, you know, PDSA, you know, in a certain sense, right.

But, you know, but it was the dogma that got, you know, and I think that also hurts, [00:45:00] like, you know, the PMI like didn't know when to change the dogma. Right. They held on, I can't chart and you cannot move forward without, you know, showing me what the, you know, where you're gonna be in stage one, stage two, stage three.

And meanwhile, the wor the move world was moving on. So, but yeah, I think that there are principles in PMI, just, like in 16, we're just like in every, that, that, that had some grounded, you know, idol is another example and we don't need to go there. But there are, you know, all these things. There were reasons why they were popular.

Jim Highsmith: Right, and I think you need to take the best parts and put 'em together, but that's actually something that I found is the most difficult for a team lead, project manager, product manager, what have you to do, which is to take things from various different areas and use 'em together.

John Willis: Yeah. No, I agree. Well, Jim, this has been great. 

How, how do people, we'll put all your stuff on, on the sort of show notes, but how do people reach [00:46:00] out and find you? What, what,

Jim Highsmith: you know? I have a website, jim highsmith.com, or they can reach me on LinkedIn.

John Willis: Okay. There you go. LinkedIn is usually the connect these days. Well, great. I, I knew this was gonna be fun and I thought it was, I, I hope you had as much fun as I did.

Jim Highsmith: Yeah, I did. Always good res somebody. That's one of our old guys.

John Willis: Yeah, that's old. Our old, old guys, right? Yeah. So we're, we're too busy meeting young people, which isn't bad. It keeps our mind sharp. But like Right. Every once in a while it's good to sort of talk to somebody who knows what a punch card is.

Right. So all right, man, that's just great.