Jim Highsmith Looking Back and Looking Forward

Transcript

Introductions [00:05]

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I have a great privilege. I'm sitting down, across many miles, with Jim Highsmith. Jim, one of the great names in our industry, has been incredibly influential over the last six decades and more. I've had the privilege of working with Jim a few times over the years, and every time it's been a joy. So I'm really looking forward to our conversations today.

Jim, welcome. Thanks for taking the time to talk to us.

Jim Highsmith: Thanks, Shane. It's really nice to be here back in New Zealand.

Shane Hastie: Some of our audience probably haven't heard of you before, so let's go right back. Tell us a little bit, the super fast version, of the Jim Highsmith story.

Foundations of agile software development and the agile mainifesto [00:50]

Jim Highsmith: Well, it's nearly 60 years, so let me hone in on the last 20 or so first, because what I'm best known for is part of the agile movement as one of the signatories of the Agile Manifesto, and I've written several books on agile development. My book, Adaptive Software Development, came out about the same time Kent Beck's Extreme Programming came out, at the end of 1999. And those were two of the initial books that sort of launched the movement in a way.

And of course, others came along really quickly and I was part of the group that wrote the Agile Manifesto. I was heavily involved in the Agile Alliance, the formation of the Agile Alliance, the Agile Project Leadership Network. I did a lot of writing of articles right after the manifesto promoting Agile Software Development or agility and the Agile Manifesto. And so I've been involved in that quite a bit.

In mid-century, I wrote a book called Agile Project Management, which is still selling a few copies now and then today, and I hope that it did with a second edition in about 2009. In the agile period that I have the book, I break the agile era into three subunits. The first is the rogue team era, the second one is the courageous executive era, and the third is the digital transformation era. And each of those have sent slightly different characteristics, and so I've written them books in each of those different areas over the years.

And as I got to look back over my career a year and a half ago or so, I started to think about all of the things I'd been involved in. And I really have this idea that a lot of people today didn't have much history of the agile movement, much less the evolution of software development. There's very little out there written about the history of software development, software engineering. So my history goes back about 60 years to the mid-'60s and I kind of started there and moved and came forward.

Shane Hastie: Thank you. And yes, well known for being a signatory of the Agile Manifesto. I will confess that your book, Adaptive Software Development, was for me one of the absolutely foundational ideas when I was working in the early 2000s, late 1990s with teams bringing these ideas to the fore. So hugely influential and just wanted to acknowledge that. But let's step right back, what was software engineering like in the 1960s?

The beginning of software engineering [03:12]

Jim Highsmith: It wasn't. At an engineering conference, an IEEE conference in about '67 or '68, software engineering got its name, but when I started working and developing in COBOL, there really wasn't any engineering about it. You’d basically learn from experience from working with mentors and from reading the COBOL manual. That was about it, and so it was very difficult back then.

And then you had things like computers back then were really slow and not much memory. I've got a picture in the book of the guy sitting down at the end of a big honking computer, feeding card decks in and getting printouts on the other end. And it would be like today sitting down to a terminal to write a program hitting the enter key and having a 12-hour delay. And so that's what I call the wild west.

We had a guy that worked beside me at Exxon. He was one of my mentors, and his office was full of card decks and printouts. I mean just every shelf, every piece on the floor, every chair had card decks and printouts. He had some special card decks that he ran at the end of the year, to close the financial books. If Ed wasn't there, you didn't close the books, there was that little backup. If he lost those decks, we were out of luck.

So that's the kind of stuff that went on back then. And then I was thinking about testing tools that we had back then too. The testing tool we had was a core dump of the entire memory in hexadecimal. And so you had to read hexadecimal, find out where the program started and go from there. Just to kind of give you an idea of what we were looking at back then, in 2021, a gigabyte of memory cost about $10. In the Wild West era, if you could have gotten that much memory, it would've cost $734 million.

Shane Hastie: Things have changed.

Jim Highsmith: And so people wonder why we had the Y2K problem. The reason we had the Y2K problem is a bunch of idiots like me had to delegate date field because memory and storage was so expensive back then. And even in the last 10 years, the cost of storage has plummeted so that you now have petabyte data warehouses. And so it's a lot different than it was back then.

And so from that early years, it sort of evolved, and so the three eras that I talked about before agile. One is the wild west which is the '60s and part of the '70s, structured methods and monumental methodologies which was basically the '80. And then as things started to change, I called the '90s the roots of agile. And each of those eras had certain business things that were going on that sort of shaped software development and some technology that shaped software development. So technology both enhanced and constrained what you could do in software development.

Shane Hastie: Structured methods, I certainly remember playing with case tools and structured systems analysis. So I'm aging myself here. I came into this in the 1980s. What did structure methods bring us compared to that wild west of the 1960s?

Structures methods and monumental methodologies [06:07]

Jim Highsmith: I think it brought a little discipline to the industry and it also brought some tools, some analytical tools that you could use to do data flows, to look at processes within an organization. And one of the things that people need to remember is back then, what we were automating was internal business processes. We were automating accounting and order processing and manufacturing, and all of those in internal things is what was going on in the 1980s.

And so having things like data-flow diagrams was a great advantage because you could actually map out the flow of processes within the organization. And so it was a good tool for the time. And people are still using data-flow diagrams. In fact, Tom DeMarco was one of the gurus at the time, and I've interviewed him for the book. One of the funny things that he talked about when I was interviewing him was that he actually ran into a piece of code way back then, and basically this program for data names used vegetable names.

And he was talking about the need to eliminate comments so that the code told your story. And so what happened, these structured tools, interrelationship diagrams, structured charts, data-flow diagrams started being used by people like Ken Orr and Tom DeMarco and Tim Lister and some others. And then in about the middle of the decade, the other thing that was advancing at the same time was the project management profession. And so you've got the rise of PMI, Project Management Institute, during that period of time, more emphasis on project management.

And so the structured tools and project management sort of intersected. And what happened was people decided, "Ah, a little bit of structure is good, but a lot of structure is better." And so we started having what I called monumental methodologies. At that point in time, they were in big four ring or three ring notebooks, four inch notebooks. There'd be five or six of them, and they would do forms and processes and checkpoints and a lot of different documentation.

So all that documentation became fairly burdensome. So aha, what do you do? Well, you automate it. And so that's when CASE tools came along. And so the CASE tool era hit in the late '80s, early '90s and drove into the next era. But we were still using sort of the philosophy of the mindset of the structured era and CASE tools didn't change that.

In fact, one of the reasons CASE tools ran into trouble, and there were a lot of reasons it did, is there was an idea back then that once you got the diagrams done, you could generate code from them and you wouldn't have to have any coders or programmers. And that didn't turn out to be true.

Shane Hastie: Yeah, we've been trying to do that for a few decades and hasn't happened yet. Well, maybe Copilot and ChatGPT, but we'll see.

The advancement of tools changes the level of abstraction needed to develop software [08:47]

Jim Highsmith: If you look back when I just talked about the '60s, we had zero tools. Our tools were a compiler. And so as we moved through time, we got more and more tools, which made the job of a developer different, but it made it at a different level. So for example, today, one of the jobs that a developer, a team of developers has to go through is they've got a software stack that may be 15 or 20 items deep, and they've got to figure out at each level what kind of software they need at that part of the stack.

So there's an enormous amount of analysis before you ever get to coding. And so what happened is what we do has changed and the job has changed. So maybe it's not quite as much coding as it was before, but it's still a software engineering-software development job.

Shane Hastie: Coming through that period of the '80s into the '90s, you talk about the roots of agile, what was happening there?

The roots of agile in the 1990’s [09:40]

Jim Highsmith: Well, let me give you an example. So about mid-decade, I was called in to do some work at Nike up in Beaverton, Oregon. And they had a project that they were working on and they had spent 18 months producing a requirements document. And the VP of the customer area was not too pleased because after 18 months, all they had was a document and it was out of date.

And so what happened was a friend of mine was working for Nike, actually he was a guy that I used to go mountaineering with a lot. And so he knew what I was doing a little bit, but I had a rapid development method, a RAD method they called it back then. And so he set me up with a meeting with the VP of IT for Nike. And my big question going into that first meeting was what to wear?

Because I knew that at Nike, you didn't want to wear a suit and tie and a button down jacket. So I went in with a nice pair of slacks, nice shirt and red Nike running shoes. And he recognized the shoes, and I got the job. And so what this was all about was this was sort of the result of monumental waterfall type methodologies. You got into this kind of business where you had 18 months and all you had was a requirements document.

And so the mantra that we kept hearing from IT managers during the '90s was, takes too long, costs too much, doesn't produce what I need. We heard that kind of thing over and over again. Then what happened is you also during that period of time had a technology revolution. For example, I used to trade stocks once in a while. Before the mid-'90s, what I would do is I would call the broker, place an order, talk to him or her for a few minutes about the stock, place an order, they would enter it into their terminal, it would get sent to New York or to Chicago to get traded. The confirmation would come back and then they would call me and let me know what it was. And I would get a slip of paper.

In the mid-1990s, I could log on, go directly to my account, trade stock without another human being being in the process. And I'm not sure that people understand how big a change that was because what happened in the mid-'90s is we went from building internal systems for internal people to building external systems for external people. And that was a huge change, particularly as it related to user interface design, because what you could use for internal people with the old character screens and what you could do for external people with the new GUI interfaces was very, very different. And it was a difficult transition for a lot of people.

And the things that made it possible were the internet, object-oriented programming and GUI interfaces. But that whole technology changed drastically in the mid-'90s, and that's why you had the dotcom bubble and the dotcom bust during the '90s. The other thing that was going on at that period of time was the culture of business was changing. In the '80s and part of the '90s, it was very command control, very deterministic. What I like to say, it was an era of plan-do, plan it out in detail and then do it.

And what happened is as the agile movement came about is you move from that to an envision-explore. You envisioned where you wanted to go in the future and you explored into that vision, which is a very different paradigm from a plan-do paradigm. And so the '90s were all of these things were sort of turning. Scrum got started in the mid-'90s. The SDM got started in the mid-'90s. My approach, the RAD got started in the mid-'90s, feature-driven development got started down in Australia. So there were a number of these things that were sort of simmering from the mid to the late '90s.

Shane Hastie: That management approach I think of people where, like Tom DeMarco, I think of Larry Constantine, I think of Jerry Weinberg. You know and knew all of these folks. What was it like working with them and collaborating with them?

Jim Highsmith: It was a blast. I mean, talk about Tom DeMarco. How often do you get to work with one of your heroes? And so during the '80s, he was really a hero of mine. And during the '90s, I got to work with him quite a bit. And so that was wonderful.

Larry Constantine may have been the person that set me on the path to rapid development and then agile. In the early 1990s, I got a call from Larry. He barely remembers this, but I do. And he had a job that people at Amdahl Computer company, it was a big computer company back then. They had something they needed done and Larry couldn't do it because he was working for IBM at the time and doing some consulting work for IBM. So he asked me if I wanted a job, and it was a job to build a rapid application process.

It would help them sell their rapid application tool. So it was a process to go with their tool that I came up with, became good friends with their marketing head, who was Sam Bayer. And we worked on a process and we would go into one of their clients, one of their prospects, and we would do one-month projects with one week iterations. And this was in the early '90s, and we must have done 20 or 30 or 40 of them. I wish I'd counted them at the time. But we did a number of those over the next few years, and that's really got me started into the rapid application development. So that was my interaction with Larry Constantine.

I spent a lot of time with Jerry Weinberg. I went to several consultants camps that he ran during the summer. So Jerry was a big influence on me from the standpoint of collaboration and open style meetings and a different management style, as I was thinking about the type of management style that needed to go along with rapid application development, adaptive development, agile development. Jerry was modeling those kinds of leadership in his workshops and in his consultants camp. So I got to know Jerry pretty well too.

Shane Hastie: I had the privilege of meeting him twice. Amazing, amazing man.

Jim Highsmith: The guy that I worked with the most, and it really changed my career was Ken Orr. And so one of the reasons I wanted to write this book or one of the things that came out of this book was to really recognize some of these pioneers in a number of different areas, both the structured era and the agile era. Because I would talk to people today and I'd say, do you know Tom DeMarco or do you know who he is? Or do you know who Larry Constantine is? Or do you know who Ken Orr is? And they'd say, "No, I know Azure, but I don't know Ken Orr."

Shane Hastie: Yeah, we stand truly on the shoulders of giants. And then in late 2000, early 2001, there were 17, went up a mountain. What brought that about?

Authoring the agile manifesto [15:49]

Jim Highsmith: Yeah. Well, actually there was a pre-manifesto meeting that Kent Beck called in Oregon. And so in 1997, I met Martin Fowler in New Zealand, and that was the first time we'd ever met each other. And he went to one of my sessions and said, oh, because he'd been involved with XP and Kent Beck at that time. He said, this guy's really on somewhat the same path.

So Martin and I met each other in New Zealand, and then Martin, we think as much as we can nail down, introduced me to Kent Beck. And then Kent Beck and I exchanged manuscripts before our two books were published, Adaptive Software Development and Extreme Programming. And Kent had a meeting in Rogue River, Oregon in the early 2000 or the fall of 2000, I don't remember exact date. And it was basically to bring XP people together to see what the future of XP could be.

And he invited a couple of outsiders, and I was one of them that went to this XP meeting where I met Ward Cunningham and Bob Martin and some other people. And that meeting then precipitated Bob Martin sending out the call, so at six months later to do the manifesto meeting. So I find that pre-meeting was how I got involved and really got involved with the XP people during that period of time.

Shane Hastie: And that snowbird meeting, I've been fortunate. I've met all 17 of you that were there, and I've heard some stories, but from your point of view, what was so special? Why did that work?

Jim Highsmith: Well, a little bit of lead up. The meeting was held using open space principles. When we started, we didn't have an agenda. We didn't have a goal. Our thing was we knew that there were some people that were doing similar kinds of things, and we knew we didn't like being called lightweight methodologist. And that was the label for us at the point in time.

And so we wanted to get together and just kind of see what happened, see if we had some common ground, see if we wanted to do something with that common ground. And besides the results that came out, I think one of the things that people don't realize, they sort of know it but they don't realize what it took. We had 17 people. They were all type A's. They were all non-conformists, they were all adventurers, all 17 signed the manifesto.

And the way that happened is, there was an incident that Alistair Cockburn told me about. He and Ron Jeffries and Steve Miller had a side conversation during the conference. Now, I don't know if you ever knew Steve, but he was not an agile methodologist. He was not a lightweight methodologist. And when he introduced himself at the meeting, he said, “I'm a spy from the structured methods”.

And so everybody got to wondering why was Steve there, and was he going to be the only nay vote when we came to doing the manifesto? And Ron, Alistair and Steve got together, and Steve started explaining what it was that he was trying to do. And Alistair and Ron listened to him and they listened to what he had to say, and they kept saying, "Well, we don't think you can do it, and we think you got a problem because you want to do diagrams and then code, and then you got to maintain the diagrams and maintain the code, and that's liable to get out of sync."

And Steve said, "No, that's not my intent. My intent is to have the diagrams generate the code and you maintain it in one place." And Alistair said, "Oh, well if that's true, then your intent is the same as our intent. We don't think you can do it, but the intentions are the same." And it was those kinds of conversations and good listening among these people that really got us to the point where we could agree on the four values at the meeting and then the principles later on. So it was a type of back and forth really trying to listen, really trying to understand that made that a very unique meeting.

Shane Hastie: And from there, the manifesto was published. I understand that there was a distributed work on the principles and how did you bring it to the world?

Jim Highsmith: That's an interesting question because there were several different things, and of course, it took off faster than any of us imagined and grew to a size that none of us had ever dreamed of when we had the meeting. So that really happened. So we went away, and for example, Martin Fowler and I wrote an article that was in Software Development magazine that was the cover article that came out in like September of the next year. Alistair Cockburn and I wrote some articles. There were other people that wrote articles as to what was going on.

One of the best things that happened, and it was completely Ward Cunningham's doing, is he put the manifesto and the principles up on a website and he added something that none of us had thought about but Ward thought about it. He added a place where people could sign on as signatories to the manifesto, and it took off. And people just kept signing up for that and basically saying, "This is great. This is wonderful." Some people didn't like it, of course, but some people would just put their names down there. Some people would write paragraphs about why they liked the manifesto or what they were doing. They finally found somebody of a kindred spirit.

And over the next 10 or 12 years, the last number I had was from 2013, 15,000 people had signed up. So the manifesto touched people in a way that structured methodologies had not. It really touched them at a gut level. It got them where they worked and said, "We want you to develop excellent software and we want you to work in an environment where you're empowered and excited about going to work." And those two things, I think are the core of the manifesto's message.

Shane Hastie: I'm one of those 15,000 people. I think I signed the manifesto in 2003, which is about when you and I met. I certainly found it an inspiration, and the opportunities to talk with yourself and Alistair and some of the others in those SDC conferences at SoftEd in New Zealand.

Agile has almost become passé today. And the state of agile surveys tell us 96%, 98% of organizations claim to be doing agile. But I don't see the difference. There are some organizations that really get it right, that are doing well. But there's a whole lot where, “we've been scrummed before” was a comment I got from somebody when we were talking about let's bring in some new ways of working. There was this fierce resistance to, oh no, not another organizational disruption. How come?

Jerry Weinberg’s Law of Strawberry Jam [22:10]

Jim Highsmith: Well, I go back to Jerry Weinberg's Law of Strawberry Jam, which is the further you spread it, the thinner it gets. And so I think that happens with any movement, any type of management or software development or technology movement is as you spread wider and wider, it gets out to more and more people, they interpret it in different ways and they don't go into it in any depth. They look at it at a very narrow place.

And one of the questions I always have for people is, how many organizations do you think should do this really, really well? What's your target? And I would say that most organizations are not going to do anything very well, much less agile. And one of the things I tell people over my 60 year career, I've seen every single methodology succeed, and I've seen every single methodology fail.

And one of the things that I've been doing in some of my writing recently in some of my presentations, I've been sort of challenging the agile community, this next generation of agileists. And one of the ways that I want to prepare them for this, and that's one of the reasons I wrote the book or has come out of the book, history's role is not to help us predict the future but to help us prepare for it. So I want to prepare people for the future by giving them some history about what happened before.

And then I've got two questions that I want to ask. How do we continue to instill agility and adaptive leadership into our enterprises at all level? So I'm not talking about agile methodologies, I'm talking about the characteristics of agility and adaptive leadership. How do we go back and extract the good things out of agile or Kanban or Lean and move forward in the future? And then secondly, how do we rekindle the inspiration, the passion, and the excitement of agile? I think we've lost some of that excitement and we're now battling some wars between the various different factions.

But I don't see any of the new factions that have excited people the way the manifesto excited people. And that's what I'm looking for and I'm looking for somebody to do that.

Shane Hastie: What will that look like?

Looking forward into the future [24:05]

Jim Highsmith: I don't know. I know that people have done several attempts at it, but I don't know exactly what it'll look like. But one thing it'll look like is taking the stuff from the Agile Manifesto and figuring out what's still valid. So for example, the focus on people and their skills and abilities and interaction, do you think that'll ever go away?

Shane Hastie: I hope not.

Jim Highsmith: The idea of exploring into the future or exploring into a project or product and envisioning and then exploring in today's high change environment, that's not going to go away, the idea of exploration and innovation and creativity. The idea of working together in collaborative groups is probably not going to go away given the challenges we face today. And this idea of emergence, of getting teams together and having them come up creatively with innovative ideas and innovative solutions, we need that today with all the issues and problems we have. So I don't think that's going to go away.

So if I look at the core attributes or behaviors or core pieces of the Agile Manifesto, I see that they have some applicability for the future. Maybe they need to be rewritten, maybe they need to be enhanced, but the core ideas are still valid, and I'd like to see people take that and then go on to the next thing.

Methods, methodology and mindset [25:22]

One of the things that I did in the book as I talk about methods, methodology, and mindset. The methods are things like structured programming or refactoring methodologies are stringing these things together into some sort of life cycle of how you go about doing stuff. And then the third one is the mindset. And I think the mindset piece of it is one of the things that people talk about a lot and that they are complaining that people don't have the right mindset. But I don't think we've figured out the best ways to try to encourage that mindset.

So, one of the things that I talk about in the book is this idea of an adventurous mindset. You've got to have some adventurous, non-conforming people in your organization or you're not going to be able to do agile. So you've got to find those people. You've got to find those people that go out and climb mountains in their off time. You've got to find those people that go off and do century bike rides on their off time. You've got to find those people that are willing to take a chance at some new idea at work. And those are the people you've got to have lead your agile transformation.

I had a client one time and we had done a pretty good job of doing some agile implementation and transformation in the company, and we left. And they brought in a guy to manage the rest of the transition, who was a micromanager, who had completely the wrong mindset to implement agile. So those are the kinds of things that we've got to identify, those kinds of activities or actions that are agile or adaptive in nature, and make sure we find enough of those people in our organizations to carry through the transformation.

Shane Hastie: Transformation, you talk about in the book, that third era of agile is digital transformation. What are we doing there and what's happening there?

The current era of digital transformation [26:58]

Jim Highsmith: Well, what's trying to happen there, and a lot of people are talking about that today, is this idea of a digital organization or a digital company that it is really wired into how to use the technology. And I just had a very interesting example of that. I'm reading a memoirs by Bob Iger, who's the CEO of Disney, and he talks about their acquisition of Pixar a number of years ago. And that one of the things that Pixar did is they were way upfront in terms of the technology they were applying to animation, whereas Disney animation studios had gotten behind the times. They were still using the old technology just about back to the flipping the pages as their tools. So they weren't up to using the technology to the greatest extent possible, whereas Pixar was.

And it's those kinds of differences between companies that I think is going to be even more important in the future as we move into a time of what I'll call punctuated equilibrium. It's a biologist term. So about 225 [million] years ago during the Permian extinction, 96% of all species on the face of the earth perished just kind of like the dinosaurs did it 65 million years ago where everything changed. So it's called a punctuated equilibrium in biology.

And I think a similar kinds of things when you think about COVID and the climate situation and the geopolitical situation and the war between Ukraine and Russia, and all of those big problems that you got to have a different way of attacking those problems. And I think we've got to grow the kind of new leaders that can do that.

Shane Hastie: What are the skills that those new leaders are going to need to bring to the world?

Jim Highsmith: I think one of the things that they're going to have to do is they're going to have to look hard at a couple of different things, one of which is their sense of what's going on in the world. An example, who developed the digital camera? It was a guy that worked for Kodak. But Kodak didn't sense they were in big trouble for years and years and years. They should have seen it coming, but they didn't. And finally, the digital cameras overwhelmed their film business, their film processing and film selling business.

So I think one thing that you've got to be able to do is you got to be able to look at what's going on in the world through a different lens. And a woman by the name of Rita McGrath, who's at the Columbia Business School wrote a book basically on sensing the future or sensing and how you go about, it's called looking around corners or something close to that.

So I think sensing is one of those things. You've got to be able to adapt as you move forward. Your iterations give you different information or new information. You've got to be willing to adapt rather than try to go to some pre-planned place, which is what we used to have to do when you now need to go towards the place that evolves as we move forward. And so I think that's a really important piece.

And I think another important piece, I'm just kind of taking these off the top of my head, is talent acquisition and management. We're in an era that's beyond the knowledge worker. We're into an era that's what I call the innovation worker. And if you want to get enough innovation workers into your company, you've got to have a really outstanding talent acquisition and management plan, or you're just not going to make it.

Shane Hastie: Who's doing this will?

Jim Highsmith: I have not worked with the science very much over the last few years, so I don't have a lot of hands-on with clients that give me that kind of information. In the mid-2000s, I think the one that stands out is Salesforce. They did a great job of bringing agile in not only to IT and to their software development, but into the whole organization.

And I think there are other companies that are doing it maybe not as rapidly. A company that's actually doing a pretty good job, I think at least in some aspects of it is IBM, believe it or not. And I take a lot of that from this book that I've just read by Ginni Rometty, who's CEO at IBM for eight years. To me after reading this book, she's the epitome of an agile leader, those kinds of things. And so if you want to see what a leader should be able to do, read that book. It's at a CEO level.

I think a lot of pundits like myself, talk a lot about leadership, but I've never sat in the CEO seat of a big corporation. Ginni Rometty did, and so I think it behooves us to listen to some of those people from time to time.

Shane Hastie: And to round us out, what's your one important message for the InfoQ community?

One important message [31:10]

Jim Highsmith: Well, I think one is to quit worrying about factions of agile methodologies, whether it's scrum or scrum fast or scrum slow or whatever the different ones are, and realize that we've got some common ground and we've got some common problems to solve and we need to get on with it.

The other thing that I would say is that I would talk to people who are kind of up and coming, so some of the newer agileists or newer software developers that are out there, and think about their career in terms of what is their purpose in life? Why are they doing what they do? What do they think is some of the goals that they want their life to achieve?

And don't try to plan it. One of the things I realized, and I wish I'd done this earlier in my career, is I didn't plan stuff, but I had a purpose of what I was trying to do. And so I changed the plans as they went along to fit the purpose. And really, if you look back a long ways, the two things that I had in mind were building better software and building better work environments. That's been a sort of catchword or a catch purpose for me for a long time, and it's only within the last 20 years that I've been able to articulate it to any degree.

But that's one of the things I talk about in the book, and I think that's something that I would try to pass along to the newer people in the field.

Shane Hastie: Jim, thank you so much for taking the time to talk to us today. It's been an absolute pleasure and truly a privilege to catch up with you.

Jim Highsmith: Yeah, it's really nice to have an opportunity to talk some more and catch up.

Mentioned

• Book: Wild West to Agile
• Agile Manifesto
• Robert Iger book: The Ride of a Lifetime
• Ginni Rometty book: Good Power