Utviklingen av Agile-prinsipper & hvordan de kan anvendes i dagens verden

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Galen Low: Hey folks, thanks for tuning in. My name is Galen Low with The Digital Project Manager. We are a community of digital professionals on a mission to help each other get skilled, get confident, and get connected so that we can amplify the value of project management in a digital world. If you want to hear more about that, head on over to thedigitalprojectmanager.com/membership.

Alright, today we are taking a journey to reimagine Agile and explore how it can be used in the future—as well as what alterations we'd need to make to have it continue to be a good fit for the ways that teams are going to be working five, ten, fifteen years from now.

Joining me today is none other than Jim Highsmith — THE Jim Highsmith — renowned Agile pioneer, co-author of the Agile Manifesto, founding member of the Agile Alliance, multifaceted technology project professional with over 60 years of experience... I could go on, but I think the accolades would probably feel like the entire episode.

So Jim, thanks so much for joining me today! It's an honor.

Jim Highsmith: Thanks Galen. I'm looking forward to it.

Galen Low: We've been jamming. I've loved our conversations. We've been talking about the future of Agile. We've been talking about reimagining Agile.

But I thought maybe I'd just dive into a juicy thing while I've got you. You are a co-author of the Agile Manifesto. And you've been an inaugural member of many of the important groups underpinning what Agile is today. In other words, you've had one of the best seats in the house to witness the evolution of Agile from the very beginning.

In what ways have you seen the tone change on conversations about Agile today versus when it was a new idea? Is it still as exciting to talk about?

Jim Highsmith: Well, it's as exciting to me. I don't know if it's as exciting to everybody. One of the things you have to realize is that Agile Manifesto was born in a different era.

I mean, it was 23 years ago, there was not a lot of social media in that period of time. So the way we got the word out was through magazine articles and speaking at conferences and Ward Cunningham's wiki. And that was about it. We got a lot of arrows shone at us in the early years because it really was a change from the past, a pretty significant change.

Except in some places, like for example, you go to Silicon Valley and you say, here's some actual stuff. And they'd say, Oh, we've been doing that. We just needed a name for it. And so I was out at one company one time in Silicon Valley, and they said they were doing Agile. And I said, well, how long are your iterations? They said, oh, three or four months.

So even there, there was some difference of opinion. The other thing too, is that there's a technology adoption life cycle that's been published for a long time. Innovative, early majority, late majority, and and in the beginning, it was a few innovative people, both companies and individuals who really got into Agile.

And now we have people in all of those different stages. We have early majority, late majority. Some people just get started. Some people that don't want to start. And so you get different kinds of feedback from each one of them. And, in the innovative area, people just go with what's a good idea.

By the time you get to the late majority, they want proof. And not only do they want proof in their industry and their kinds of project. And they're liable to say, no, we can't do that because of X, Y, Z. So you're always going to get mixed responses to these kinds of questions. One of the things I've noticed, and I've done everything from no methodology to structured methodologies to agile methodologies is that every one of them works and every one of them doesn't work.

It's more about the people than it is the methodology. And really it's about the mindset. And I've been using the words 'accomplishments and disappointments' rather than 'success and failure'. Because I think every project, whether it's Agile, Waterfall, no matter what, has some accomplishments. People say, waterfall doesn't work.

Well, during the 1980s, I did plenty of projects using Waterfall and it was very successful. We accomplished a lot. There were also some disappointments and some of the disappointments caught up with us in the mid nineties. I wrote a definition of agility in 2002 book. Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.

And I don't know that I changed that much today. It's agility. And I think one of the things that happens is that people get mixed up about methods, methodology, and mindset. And those are three distinct things that we could go into a little bit later if we want to. But in essence, the tone has changed in looking at agile.

And one of the things that I'm trying to do with this reimagined agile initiative is to rechange the tone back to a more positive tone.

Galen Low: I really like that angle of it's not just the early adopting crowd. Now you have this spectrum of people who are lagging and who are sort of late to adopt and the proof that they need.

And the burden of proof is different now than when it was before. And I love what you're saying about the fact that the world keeps turning, agility is seen as valuable these days, but it doesn't mean that Waterfall doesn't work anymore. It just might have a different sort of purpose or focus, or you can expect different disappointments and accomplishments from them, but it doesn't mean that they are out of date.

Jim Highsmith: One of the things that I think has gotten lost sometimes is the fact that you need to look at projects in the context of those projects, particularly around uncertainty. So for example, a project like the Webb Telescope project is very different from doing an app on your iPhone in terms of the use case. And you have to understand that when you go to manage a project in particular.

Galen Low: I love that you use that example, cause we often go to these sort of aeronautical space examples, because in a world of software and you have, continuous integration, you're deploying all the time, it's relatively easy.

I'm not gonna say it's easy, but it's certainly a lot easier than shooting a shuttle up to the space station for a resupply mission or to fix a thing, a piece of equipment that wasn't working the way you had expected. And you need to plan differently and you need to budget differently and you need to just think about that project differently.

Jim Highsmith: Yeah. It's interesting you say aerospace because one of the things I had years ago in the early 2000s, I had a discussion with the secretary of the air force. And she had read my first book and she was saying, in building aerospace project, maybe we need to have iterations and maybe they cannot be a year or two years.

So she used the idea of adaptive development in one of her speeches. And so it's not that all aerospace projects have to be Waterfall, but they can be somewhat adaptive and Agile. And I think that's an important piece to reimagine ourselves are.

Galen Low: Earlier I scoffed at this sort of notion of a three to four month sprint. But sometimes in the grand scheme of things, that is nimble. That is fast. That is like a very quick rotation to get results, learn from it, and make sure you don't go 15 years building the wrong thing. It's still the right mindset, even if, I think, just coming back to what you said earlier, and if I'm picking up what you're putting down, there's the methods, there's the methodologies, and the mindsets, and we get them mixed up all the time.

Sometimes we want some of these mindsets to have all of these like codified rules and things, rules that you don't break. But really, it's actually just a way of thinking about it to avoid some of the other disappointments that would have come along with doing things a different way.

Jim Highsmith: I mean, you can take any of the practices, say sprint planning. And you can burden them with documentation in meetings, and they can become very prescriptive or they could be adaptive. So you can take the same practice and depending on how you approach it, it's gonna be more prescriptive or more adaptive.

Galen Low: All of the benefits that people herald about a thing, anything, not just Agile, could also just be their downfall. It could become untrue in the wrong hands.

Jim Highsmith: And the other thing too is that with the arrival of social media, the 10% have a louder voice than the 90%. And 10% like to be negative. I don't know if you remember the Spiro Agnew, but he was the vice president under Dick Nixon. He was famous for a phrase, "the nattering nabobs of negativity".

And I thought about that when I was getting ready for this. I said, that's the problem with, know, 10% of the people on some of these social medians is there a nabobs of negativity.

Galen Low: It's funny and I'm glad you mentioned social media because a lot of people's introduction to Agile these days is through controversy, is through somebody on Reddit or somebody on social media, usually from a negative lens. One way or the other, why are people still using Waterfall or what's the big deal about Agile? It never works. And they're coming at it from these like really extreme sort of polar ends of things. And to your point now, like they are loud, right?

It's not like just the handful of people who listened to that radio program or saw that billboard or read that academic paper. It's like everyone practically, it shows up in their feed. They're sort of getting these sort of impressions into their head. But coming back to your example, like in politics.

This is a project methodology you wouldn't think it's so controversial and contentious, but it is, and we've been arguing about it, it appears to be 20 plus years of us arguing passionately about whether Agile is good or not. And I think we're still arguing about it. I'm like, why are we still arguing about it?

And like, why is it so contentious and why haven't we quite gotten over it in 20 odd years?

Jim Highsmith: Right. And some people, for example, I saw a post on LinkedIn earlier in the spring, and it was talking about the problems with Agile approaches. And it talked about the fact that there was no documentation and there were several others like that.

And I said, we answered those questions 20 years ago, where you've been? And so one of the guys just happened about a month ago, I was looking through my project management book. It was published in 2009, Agile Project Management. And I happened to notice a chart in there that I had forgotten about documentation.

And I thought, well, okay, this is something that I looked at a more balanced approach to documentation and gave some guidelines. And so I posted it on the internet, just like it flows. I didn't modify it. I didn't change it at all. It is at 66,000 impressions and 96 reposts and something that I thought that was not that interesting. Documentation guidelines, this shows you that there are a lot of people out there who are looking for good balanced information away from the extremes.

I'll say that, but I'll also say, we needed the extremes back in the day because we needed to look at the boundaries. So for example, documentation, maybe in the day, somebody said, let's try no documentation. Nobody really means that what we were talking about was documentation had replaced communication and collaboration.

What was a fallout from the Waterfall was you got organizations that followed the Waterfall. So you had a requirements group, you had a design group, you had a programming group, you had a testing group. And the communication between them was all documentation. And so there wasn't this collaboration.

There wasn't this interactive communication back then. And that's what we were trying to get away from is the essence of, you wanted the documentation to supplement your collaboration, not the other way around.

Galen Low: It's funny because we talk in language like, the Agile revolution, big change, upheaval. You're right, I mean, lots of time has passed and we don't quite sort of appreciate the push that was needed then. When you think about revolutions, when you think about sort of arguing from an extreme to make change happen, I think a lot of people took it maybe too literally. And then I think people keep continuing to misinterpret it conveniently for themselves, because from what I've seen, it doesn't sound like no documentation.

It's just like it's communication over documentation in terms of its principle.

Jim Highsmith: It's about interpretation. It's sort of like the US constitution. There are justices who are strict interpretationists. What it says in the Constitution is what it's like. So if it says in the Agile Manifesto, if it says software, they have this for software.

And there are others who have a looser interpretation who recognize that Agile can evolve, that the manifesto is not cast in stone. It was a particular point in time. And so we need to find ways to extend that into other areas and not get hung up on the exact wording.

Galen Low: It's not an Agile problem. It's a human problem. And that is equally applicable, really interpreting it to the letter of the law or grasping the essence enough that we can carry it forward and then everything in between and is that okay, which actually, that's what we're going to dive into. Because I think the thing that folks don't always appreciate is that Agile is changing.

I think you've seen that. I'm just wondering what are some emerging trends or practices in Agile project management that have caught your eye recently?

Jim Highsmith: It's interesting that I think there's some people out there who are doing the extensions to the basic Agile approach. So, for example, in 2004, 2005, as we started up the Agile conferences, I was concerned because there was so much negativism in the Agile community towards project management.

That's why we came up with scrum masters and some other designations because we don't need any more damn project managers. We need scrum masters. I think that's been an issue for a long time. So I've found an organization in 2005 called The Agile Project Leadership Network. Our mission was to extend project management into Agile and basically say, it's not that project management is not any good. It's that we need a different type of project management.

We need a type of project management that focused on people more than tasks and focused on collaboration and focused on some other things. And so we started that and that's actually the group that some of us migrated into PMI to do the Agile PMI certification. I think that there always been sort of as extensions, and people like David Pereira, he's got a new book coming out on product management and I wrote the forward for his book.

And one of the things I liked about it is, you read through this book and it's all about agility, but he never uses the word agile and agility, maybe a couple of times in the whole book, but it's all about the concept of agility. There are other people like this. Chris Stone is another one who's really moved forward with his approach to software development, and doesn't always have to use the word Agile. Of course, the big area that's coming up is AI. I've seen some people that have been using the term Hog Bedded Agile, which I think is probably appropriate for the time.

Galen Low: I'm wondering, you said earlier, when you were writing the manifesto and it was getting released, you were getting shot at with arrows, people were coming after you, people were sort of angry at change.

And then we have this notion of extensions of Agile and are some of these folks also getting shot at with arrows? Are they like not using the word Agile on purpose so that it doesn't turn people off or so that they don't get shot at?

Jim Highsmith: There is some of that, yes, because there are some people that are sort of abandoning the term because it's gotten some bad press.

Interestingly enough, where it's getting good press today is in the business community. For example, if you look at some of the announcements by CEOs of where they're going, the CEO of GM has used the word agility. The CEO of Bayer, they've got a new practice underway, they've used the word agility. And so in a business environment, it is being used more and more.

And in particular, for example, Steve Denning has written several articles recently in Forbes about implementing Agile methodologies for an Agile of mindset has really been important to some of the top companies today.

Galen Low: Yeah, I've seen a lot more of that. And it it sparks some conversations in our community about, what do they mean?

Is there going to be like scrum for executive, like strategic planning and strategic execution? Or is it more about that mindset? And again, right, we're getting tangled in this notion of methods and methodologies and mindsets. And I think it's probably all three, but we just need to not let them get tangled.

Jim Highsmith: For example, there is a, the association now, the agile marketing association, who's taking agile principles and applying them to marketing and being fairly successful at it. So I think what you're going to find is you'll find an extension for marketing more than one extension. You'll find some extensions around artificial intelligence, some in different industries, and no, I don't think you'll have sprint play in the C-suite.

But you'll have more agile adaptive ways of looking at this. Just an example, in terms of organization structure. I was listening to an incredible presentation by the CEO of NVIDIA. One of the things he was talking about was the fact that their newest chip has 208 billion transistors on it. When I started, transistor was about his biggest end of your finger.

If you took that and multiply it by 208 billion, you ended up with 10 square miles. There's just a big difference in the technology today than there was even five years ago. And one of the things that I've been talking to groups about, and I I have a woman come up to me after I talk recently, and she said, you really inspired me and you scared me to death.

I was talking about education and training and all of those kinds of things. And I was saying that whoever you are, if you were a scrum master, if you were a project manager, if you were an agile coach, if you had to have some technology background, you couldn't escape it anymore. And I think that's shaken some people up.

Galen Low: It's a really interesting, like I have to step out of my shoes sometimes too, because like you said, in the manifesto, it's talking about software and there's a lot of things I look at today and I'm being extreme. But I'll be like, duh, but it's not duh for a lot of other industries. And I'm happy to see that business and marketing and other areas are opening their processes up and opening up their methods to be more nimble, more agile.

And they've got to find their own path too. I mean, it doesn't really help for someone to stand on the top of the mountain and be like, figure it out already. And it also doesn't help anybody to be like, no, this is my top of the mountain. You guys stay down there and don't even think about this.

It has a lot of opportunity to be a lot more collaborative. And I think exactly what you're saying, right? It's like, where is change happening the most? Where is agility required the most? And it's going to be around technology and it's going to be around business. And I think as a result, yes, it's terrifying.

Yes, it's inspiring. And I do think it needs to come together and then start growing together, I guess. We need to take it forward. And I guess maybe that is the sort of reimagining agile part.

Jim Highsmith: And part of it is reimagining management to get back to the end video presentation that I saw, the CEO of NVIDIA has 55 direct reports. That's called flattening the organization. Now you got to manage a lot differently if you've got 55 direct reports, then if you've got three or four. And that was a really interesting that you see him talking about how he managed differently, because he had so many people reporting to it. And that's the kind of thing in terms of management that we've got to sort of reimagine.

I'll give you another example from the other end of it. I have a friend of mine who's a consultant, went in to do some agile transformations for somebody and found that they had a hundred software developers and 98 project managers. And it was a little bit out of whack, but what part of the problem was they had functional silos, analyts, designers, coders, testers.

And each person had maybe seven or eight projects they were working on. So the combination of the two required a lot of project management to keep all the coordination going. And so one of the fixes there obviously was to streamline the organization and reduce the number of project management and increase the number of technical people.

And I think that's another area that we've got out of whack is the mix of management types, collaboration types, and technical types. And I think the technical aspects of agile have sometimes been not given enough weight.

Galen Low: That makes tons of sense. Actually, it's funny because, we were talking about this sort of, arguing from an extreme.

And me as a project manager and someone who represents project managers, like I'm willing to admit there's bad project managers out there. And there probably was this need to go from, all right, we need to imagine a team that maybe there isn't a project manager. And then as our technology projects, especially have gotten more complex and there's needed to be more coordination, oh it does make sense for there to be a project manager.

And then I guess the other middle ground is it might not just be the roles clashing as much as it is in all the like social media, like all the memes and things like that and people sort of venting, maybe it's just the balance. It's the mix, right? It's how we've configured these people together and these roles together and where we're putting that priority.

No longer probably in documentation for an Agile project, and there probably should be more emphasis on some of the technical roles. And I think the technical roles and the way we are conceiving of them are not just technical roles anymore. We're talking about quite capable business thinkers, as well as people who can code.

And who are good at working with people and all of these sort of stereotypes and archetypes that we had where you could make them the butt end of a joke, actually, they're not true anymore. And therefore our configurations do need to change. Our mixes do need to change. Agile seems to be, a good future answer, but there's challenges on the horizon.

And I was just wondering, what challenges do you see Agile methodologies facing today? And also, what are some of the challenges that are going to be on the horizon? And why do we need to reimagine Agile at all?

Jim Highsmith: Well, I think we need to reimagine it because of those changes. People are talking about AI today, but there's also Web3, there's also blockchain, there's the cloud, there's big data, there's a number of technology changes that are in the way.

And then in three to five years, if we get quantum computing, it's really going to change things, depending on how quickly they could build applications that are useful to businesses and organizations. So I think the technology changes are getting in touch with those and getting the right kind of impetus behind it in an organization is really going to be hard.

Let's get away from agile, for example. Let's take another big change over the last 10 years. Big data. There's a book that's just been written about the evolution of big data over that period of time and how 90% of the problems or the disappointments with big data implementations was cultural and 10% was technology.

If you think about agile following the same kind of path, I think we're actually beating big data in terms of the transformation effectiveness, but there's still a lot of long way to go. And a lot of it has to do with mindset, I look at mindset as an individual person's mindset and culture as an aggregate of all the mindsets in a company.

So I use those two words a little bit differently. And I think coming up with those and changes in numbers, we don't seem to be getting any better at cultural and mindset change. And so how are we going to do that? How are we going to accelerate that change? And so one of the things I've been thinking about quite a bit is this idea of a capability as opposed to knowledge. Because once you get into AI and you start talking about a knowledge engine, knowledge is one thing. And so I can use AI and I often do for things that are knowledge based, do some research, but capability is different. Capability is a function of knowledge plus experience plus decision making.

And so it's not enough to go get a couple of certificates about Scrum or Kanban or any of those things. It's not enough just to have the knowledge. You've got to have some experience and how can we increase the speed of those experiences? Can you get experience other than through experience? So, for example, one of the ways to do that is the way Harvard Business School does with case studies.

You get a small group of people and you give them a case study and they argue it to death and then they present it to the rest of the client. That's experiential kinds of things because it's really in depth analysis of those things. And so there are some ways that you can increase experience without actually experiencing something.

And the next level is, do you have enough experience and knowledge to make good decisions? And how do you know what kind of decisions to make? And then there are type one and type two decisions. And so there's a whole spectrum of things there, and AI is going to impact each of those in a different way.

And so, are you just looking for awareness, are you looking for an assistant, or are you looking for augmentation from your AI systems? And so I think getting those is going to be really difficult because you've got a lot of different things to think about today in terms of the technology.

Galen Low: I couldn't agree more. I mean, everything's moving really fast. And it's funny when you start thinking about iterations, we talk about sprints, right? And we look at it from an efficiency lens and we do look at it from a learning lens, but usually we're looking at it from a technical learning lens so that we don't exponentially magnify our mistakes and only look at it at the end.

But arguably the sort of learn fast, fail fast mindset is for us. It's actually for humans. So that we can actually be learning quite deliberately every time. And I know that doesn't quite hit the nail on the head in terms of getting experience without getting experience, but we can also use our short bursts of experiences to learn as much as we can from it and be reflective about it so that we can sort of get better as humans and actually get better at, I think you hit the nail on the head when you said it's not usually the technology.

It's we haven't gotten good at cultural change. The actual controversy around agile anything, part of it's just yeah, getting in the weeds about interpretation, but a lot of it is just resistance to change that seems like it's jumping from a place of lots of structure and security and predictability into an area where it's a little bit looser and more ambiguous and unknown. And I think it's that human mechanism that sometimes makes people resistant to something like Agile.

Jim Highsmith: There's something to be said for iterations in terms of learning. Let's take a project that was going to take a year and you do it as a Waterfall project, you get to do the requirements definition once, design once, programming once, you get to do testing once.

If you do it in an Agile framework, let's say you do it monthly releases. You get to go through all of those learning cycles 12 times, as opposed to one time. And so it encourages that learning process. And one of the things that I despair of a little bit is something I'll call prescriptive agility, which is a oxymoron, but that's where some people get.

They get into let's do these six things and you have to do these six things and you have to measure it this way. And it, so it becomes prescriptive. If you're prescriptive with agility, you'll never learn enough to get good experience and then modify what you do it. And so, as opposed to what I call adaptive agility, which is the way it should be.

And I shouldn't need the modifier, but I do sometimes these days. And so I think this idea of prescriptive agility is what a lot of people in the industry are complaining about. And the other part of that is agility, agile methodologies have spread wide. And as Jerry Weinberg used to say, his love raspberry jam, why do you spread it the thinner it gets? At the edges out here, we have people that have been to a two day scrum master course, teaching scrum master.

Galen Low: Yeah.

Jim Highsmith: And so naturally that I have some issues there.

Galen Low: It's something that, a) I'm glad we didn't keep it in a bottle, right? Hog it for ourselves. But at the same time, yeah, when something is widespread, it is subject to bad actors. Sometimes just people who don't know that they're bad actors doing a bad thing, just misrepresenting or mispracticing, misinterpreting, and it gets a little diluted. I think that is a challenge area.

Returning back to, your mission on sort of reimagining agile, like I can see the need for it. I guess that's question is just how? What strategies have you been working on or that do you envision for addressing some of the challenges ahead?

Jim Highsmith: Well, one of the things that we've done is we've set up a reimagining agile initiative. There's a core group of, we call them ourselves The Launch Group.

We're only trying to launch this thing. We're not trying to manage it. And so we've got a website and we're doing several presentations coming up at different conferences on reimagining agile back to basics, which is the mindset stuff. And then forward to the future, how are we going to manage that?

How are we going to make it go forward in the future? And then I'm involved in a conference in Portugal in September, which is looking at management reimagination. Not only how do we do Agile development in an AI environment, but how do we do leadership and management in an AI environment? I'm involved in some experimentation processes there because it's not straightforward.

With the height of the site cycle right now, you gotta be careful what you try to do. I think as we move forward with Agile, as I said earlier, I liked the term augmented Agile. I mean, there's no question it's going to impact each of the areas of software development differently all the way from programming and testing all the way up to finding requirements.

And so it's going to change. And I think if you try to think about the same practices, you're going to be in trouble. The same methods. What you've got to do is to have the right mindset to say, okay, this is a practice that we used to do. But we don't need to do this anymore because AI is going to take advantage of that and we're not going to have to do it.

So, for example, Martin Fowler wrote a book on Refactoring and Refactoring is a pretty interesting exercise to go back and make it better.

Galen Low: Right.

Jim Highsmith: Well, what if you have an automatic refactoring tool? They might become subsumed in the tool and you don't have to worry as much about refactoring other than you've got to be able to, and somebody has called it rather than prompt engineering, it's got to be prompt imagination. What are the kinds of things that you can imagine that would help refactor at a different level? So there's still room for the knowledge and the understanding of refactoring from a mindset approach, but the practices themselves are going to change because of artificial intelligence or other technologies.

Galen Low: And is that the analog for reimagining agile? In other words, you are a launch team, you are going to start down a path of refactoring Agile. But more importantly, you're building the machinery so that Agile can refactor itself over time. Because we're at this moment where we do need to go back to basics in order to go forward to the future.

But instead of coming back here again in 20 years, Agile should just evolve, should just refactor itself. Is that the dream?

Jim Highsmith: Right. I hadn't thought about it in terms of refactoring, but I think you're right. I think that's part of the goal we have. We want people to understand that Agile has not been a disaster. It's been highly successful in many different places. And that there are some disappointments with Agile that we've got to address. What we've really got to do is address how it's going to adapt or refactor in the future. And that's where I'm switching back to the basics to looking at it in the future.

We've got a website that we've got a lot of great stuff on it yet. And we're trying to involve other organizations. So, for example, we've got the Agile Alliance that has gotten to the group to do several panel sessions at different conferences. And we're going to do a panel session at the Agile conference in Dallas this year.

And I would welcome, for example, the Scrum Organization to take on this initiative of back to basics forward to the future, we're not denominational in our approach. And so, for example, it's one of the reasons that I looked into what are the disappointments with agile and try to do a root cause analysis rather than saying X, Y, Z is terrible.

What is it about the process that they went through that's disappointing? And how could we learn from that and apply it across the board, whether you're doing Kanban, or Scrum, or XP or any of the, or DevOps.

Galen Low: I like the sort of non denominational approach. And it strikes me that because of the scale and success of Agile, now your effort is at state level diplomacy.

It feels like you're bringing together all of these, bodies and associations and these factions, for lack of a better word, that see themselves as separate. But there is a sort of moment of unity that's required in order for us to get ahead, otherwise we are just that jelly spread super thin, and we don't see the other side of the bread as being covered in jelly. And that's different jelly, oh, yeah, that's that's not us, we're fragmented.

Jim Highsmith: We've talked about this in several different ways. And one of the critical skills for anybody who wants to be agile, whether you're a programmer or you're the CEO of the company, is to understand balance. You're always balancing off creativity versus control, or collaboration versus kind of direction.

And from an organizational standpoint, your culture has to adapt to where you are at a particular time and where you need to get to. On a scale of 1 to 10 on the agile scale, 10 being the most agile, 1 being not agile at all. Maybe you're trying to move from a 1 to a 3. It's going to be a little bit more agile, but not as agile as say Google or Microsoft or another organization.

How you do that, it's going to be very different than how you move from seven to eight or how you move from basically four to six. There's a point in there, which it's very difficult. Carol Dweck has written a book on Mindset, and she talks about the fact that there are two kinds, basic kinds of mindset.

The growth mindset, it's really a medical change and a fixed mindset that isn't, and you need some of both. But unfortunately, what happens in big organizations over time is you get a much higher percentage of fixed and growth, and that's a very hard change to make. It means that if you're at a one and you want to move to a three or four, you may need to think about some of those fixed mindset people and whether they are really gonna restrict your ability to move.

And do you have enough growth mindset people to make that? It's not enough to have one at the top or one at the bottom. You've got to have somebody at every level who's willing to take that on. And so that's part of the problems with culture change. It's changing that basically growth, fixed mindset approach.

Galen Low: It's really interesting as well, the gradient, right? And I think a lot of us are programmed to want it to be binary, to want to flip a switch, agile transformation overnight, but actually going from one to three is also good.

Jim Highsmith: It's interesting too, in terms of context, I used to speak a long time ago at several PMI organizational conferences and things. And one of the things that I would do is I would say, do you have projects in which you have a pretty definite requirements and you have a known technology that you're using?

And they'd say, yes, we do. And then I'd say, do you have some projects that are far out there, bleeding edge technology and very uncertain requirements? They say, yes. And then I say, and do you measure success the same way on both those projects? And they would say, oops. And do you manage those projects the same?

And that's what I mean about context and balance. You've got to understand the context that you're working in and you've got to understand the balance. No documentation to complete over documentation, whereas the balance points that you need to be. Short term planning versus long term planning. Where do you need to be?

One of my concerns about some of the short term planning and particularly the kind of a featureitis approach is that we lose track of the fact that there's actually a goal in line. It's a longer term goal than just getting 36 new features in today. And sometimes we lose that long term plan because everybody says you can't do any long term plan.

And so, one of the things I do is I go back to the word that I used in my first book, which was speculation. You don't need to plan, you need to speculate. You need to envision where you want to go, not plan it out in detail the way we used to do it. But you still got to have an idea of where you're going, what's the outcome you're looking for.

Galen Low: What's super interesting to me is when you say it, it's so obvious, but we've created camps more than we've created techniques. And so we're trying to, cook a turkey the same way that we would make a salad because we are agile, we're an agile, we only do this one way.

And then when you really break it down, you're like, well, if you have high ambiguity, maybe this, and if you have a high requirement for predictability and like stable requirements, maybe this. It's not spatula versus fork, I don't know, to take the metaphor too far. It's yeah, when should we use the spatula versus another tool.

And I like the thing you said about bringing people together as a sort of non denominational, I think is the word you used. In other words we're not representing any camp, let's just get back together so that we can refactor agile so that it can move forward. Because there are these disappointments that are plaguing everyone who's using it or not using it, and how do we sort of get beyond those and learn from them, I guess.

From where you stand, just project methodologies in general, projects in general, I guess the way that we collaborate and deliver outcomes together, like where is the future headed more specifically, coming back to your speculation thing, how do we prepare for an unknown future?

Jim Highsmith: When I was working on my book on Wild West to Agile that was published last year, I started chapter nine, which was the final chapter.

And I said to myself, well, this is where I want to predict the future. And I said, nah, that's not going to make it. Predicting the future is a, not a very good thing to try. So I realized because I'd written sort of a history of software development from a personal perspective, that what I was interested in is how history can help prepare you for the future, not how to predict the future.

When I started looking at that's one of the reasons that I went ahead and did the steps to prepare. First one is to try to understand historical patterns. So one of the things that I try to do when I'm writing something today is I'll go back and I'll pick a piece of history. And so I just wrote a thing on structured methods and what I call monumental methodology of the eighties to give people an idea of this is not the first time some of this stuff has happened. AI has been on a up and down curve for 30 years or 40 years in terms of hype cycles and low cycles and hype cycles and low cycle.

And I think there are a lot of people that they have, don't have a sense of history and I think it can help. You've got to change the mindset and the culture. And we've got to find ways of doing that better. There's been so many books written about change management and from so many different perspectives, we're bumping up against what it takes to be human. And maybe we're doing as good as we can, but maybe there's some things we could do to improve that.

As I've mentioned, I think one of the ways we can prepare for the future is redesigning the organization. And so part of that is flattening it. Part of that is teaching or having the right kinds of training and experience for both managers and employees. And you're going to have to ramp up the training.

There's no longer a career path. It's an obstacle course. And each of us is going to be responsible for plotting our ways through that obstacle course. So, for example, let's say I'm looking at the future and I'm saying, I need to know more about AI. Where do I start? What do I look at? How do I find people that are going to give me some good information? What classes do I go to?

I was just looking at something. Course C has a basic AI course, 5000 people took it last year. 400,000 people have taken it already this year. And so where are we going to get that knowledge and how are we going to get it? So I think that's a really, we've got to accelerate our capability improvement. And again, capability is knowledge, function of knowledge, experience, and decision making.

How do we do that better? It's not enough just to get the knowledge. I used to have some concerns about certifications and the proliferation of certifications in our industry. And I still have some issues with it, but I have come to look at those as the same thing as boy or girl scout marriage badges.

I've got some marriage badges. All that tells me is I've gotten a little bit of basic knowledge. And so I don't really guess the certifications anymore, although I do sometimes get a chuckle out of somebody that has 19 certifications out to their name. And I think we've got to, again, technology is going to become even more important.

There's another book out about the coming wave. It talked not only about AI, but talked about biotech. In fact, that those are going to interact with each other. So for example, if you have an AI engine that is oriented towards cell manipulation, and you have estimates, biological instruments that can be reduced in cost.

Pretty soon you've got the ability at many levels to do jeep manipulation. If that's a scary prospect as much as AI. And so there are all these kinds of technological things that, whether you're a project manager or a mid level manager or a CEO or a CIO, you've got to have this technical understanding and knowledge.

That doesn't mean you know how to program a computer, but it means that you need to have more technical background than we've ever had before.

Galen Low: So decision making through our experience and knowledge is the way that we've always moved forward. What if I'm really refreshing about that in some ways? Cause you know, we're talking about this kind of haunting yet fascinating ghost called AI that has suddenly appeared and yet has been around for 30 years.

And we're talking about constitutions and we're talking about how we've done change in the past, not necessarily changing agile, but changing the way we work together or changing the way we communicate or changing the principles and the mindsets that we're relying on. Have we gotten good at it? No. Will we get good at it this time just by looking at Agile? No, but it all is part of the same exercise.

Jim Highsmith: We do it incrementally better.

Galen Low: Yeah. Incrementally better. We'll get the machine that refactors itself. And yeah, then we'll be comfortably doing biotech genetic two week sprints. Releasing a new being every two weeks.

Jim Highsmith: I'll go back to my friend Gerald Weinberg who wrote a book years ago in the eighties called Secrets of Consulting. And he said, if you go into an organization and you think you're going to change it by more than 10%, you're fooling yourself.

Galen Low: It's entirely fair. No, I really like that. Jim, this has been lovely. Thank you so much for coming on the show. So many gems here. We'd love to have you back. I know you talked about some of the framework around this sort of dissatisfactions around agile.

We'd love to dig more into that. For now, I think we've given our listeners a meaty chunk and I really appreciate it.

Jim Highsmith: Well, thank you. I've enjoyed it and would enjoy doing it again sometime.

Galen Low: Before I let you go, your most recent book, where can people find that?

Jim Highsmith: They can find it on any of their booksellers. It's Wild West to Agile. It really is a half software development history and half personal memoir.

Galen Low: I love that. Awesome. I'll include it in the show notes below.

Jim Highsmith: Thank you.

Galen Low: All right folks, there you have it. As always, if you'd like to join the conversation with over a thousand like-minded project management champions, come join our collective! Head on over to thedigitalprojectmanager.com/membership to learn more. And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com.

Until next time, thanks for listening.