Almost 23 years after creating the Agile Manifesto, Jim Highsmith is leading the Reimagining Agile initiative. During this live session recorded on February 14, 2024 Jim and Luke Hohmann reviewed the origins and foundations of Agile, including what has gone right and what hasn’t gone as well as expected. They explored the future of Agile including the impact of AI and the evolution of tools that support collaboration. Questions and comments drive the lively conversation.
Reimagining Agile is part of the Miro + Applied Frameworks Agile Expert Webinar Series dedicated to the advancement of agile and lean practices. Check out other episodes in the series: Prioritizing Prioritization, Context is King, Design in SAFe, Roadmaps/Now-Next-Later, Starting and Ending Sprints with Remote Teams.
The last 20 minutes of the session was devoted to Live Questions & Answers, however there were over 40 questions submitted! Jim & Luke are working to provide written answers as soon as possible! Join our email list (subscribe below) to get notified when answers are posted.
Transcript generated with the use of Otter.ai and minimally edited. Please excuse grammar and misspellings.
Lisa Castelien 00:00
Welcome! We'll be sure to share the recording at the end of the webinar through email. And if you have any questions or comments, today's session really is going to be shaped with the input from today's audience. So make sure that you post your questions in the q&a box. As you can already tell, we have a lot of people joining us today and their chat is growing really fast. So if you want to increase your chances of us picking up on your questions and making sure that we can feed them into Jim and Luke's conversation, make sure to post them in the q&a section and we'll try and get them answered today. So all that's left for now for me to do is introduce our two great speakers of today starting with Luke who I've already mentioned. My co host of today. He joins us from applied frameworks, which is a partner of this webinar series. And Luke specifically has asked me to introduce him as not only our partner, but also a man who provides positive energy to systems that need it. And I can already tell you having worked with Luke for a couple of months already that the positivity that he brings into every conversation really is contagious, so I'm excited for him to bring in his positive energy to today's conversation. Luke, thanks so much for joining us today. And then we also have our guest speaker, and I'm excited to announce that we are joined by Jim Highsmith. Jim, as you probably will already all know, is was basically the foundational person when it comes to the original Agile Manifesto. And we get a chance to hear him talk to look today about basically what has gone well, but also what hasn't gone well when it comes to Agile or what hasn't gone as well as we had hoped. And then also, to hear them speak a little bit more about the future of agile including AI and like all of the opportunities that we see there. I think there's many ways to introduce Jim, but I think the three key words I'd like to use here are Jim is an adventurer, a catalyst and a storyteller, and I can't wait to sit back and hear him tell his stories today. So look, and Jim, over to you. And yeah, let's kick it off.
Luke Hohmann 02:26
Alright, so thanks so much, Lisa. So, when you talk to people like Jim and me, we've got some pretty deep history with agile and Jim's history is even further so I think some of our audience Jim would benefit from some pre agile history. And one of the things I like to talk about was that before we call it agile, we used to call it like iterative and incremental development or I D, or very Boehm called it the spiral method and there were other names and so the problem that I had with IID is that I ID sounds like a disease that you don't really want to watch. And spiral sounds like you could be spiraling off into infinity or spiraling down the drain or doing something that doesn't sound very good and so agile sounds like something you want to do. And so my question is, is agile really just a better name? Is it better marketing? Or is it a little bit more than just better marketing?
Jim Highsmith 03:32
Oh, by the way, I appreciate the opportunity. To spend some time with you. We haven't. We aren't connected in a few years. And so this is a good opportunity to do that. And I really appreciate it. I'll talk about that in just a minute because I think it's more than marketing. If you think of bad things like the spiral model, and some of the stuff that went before rapid application development. It was all leading up it was all background, I read all of that stuff, including Tom Gilbert stuff. Very themed stuff, and and even before it goes back further than that, but let me just start a little further back in the mid 60s When I was just coming out of engineering school, and we were designing circuits with transistors that were about the size of the end of a pencil. Today Microsoft has a new AI chip though AI chip that has 105 billion transistors on it. If you took the area of the pen and blew it up 105 billion times. It would be something on the order of two square miles, about the size of Hoboken, New Jersey. That's how far we've come just in terms of processors and speeds and the shrinking of chips in that period of time. So I started to skip from there to the early 90s. And what was going on in the 90s was pre kind of pre was kind of pre agile, we call it rapid application development muttrah During the 90s as things begin to heat up and change or rapidly was it was from IT managers and execs, I said three things. It takes too long, cost too much delivers the wrong product. And then I'll give you an example of that. In about 1995 I was asked to come in to Nike in Portland, Oregon, or Washington, Oregon, to help them with a project. They had spent 218 months on this project for a parallel department. And they had up requirements document that was out of date. They had no code, no design. All they had was a requirements document after 18 months. So a friend of mine was in there. And I had been talking to him about this rapid application development stuff I had been doing. And so he invited me in to talk to the CIO of the company. And so Nike was a very laid back place. And so my biggest question mark going into interview the CIO was what to wear. And so what I ended up doing was, you know, slacks and a nice shirt and red Nike running shoes, and he recognized the shoes and I got the job. So I just cut the shoes, because of what I had what I had to say, we took that project, and then one week, one month iterations, six one month iterations. And generated application that they put out put into play at the end of that six months. That was the kind of thing that was going on in the 90s. There were three domains and three technologies that kind of drove things in the 90s. The three domains were object oriented programming was coming along. There was a difference in aerospace engineering and what I call the structured development stuff that was being done in business, the aerospace engineering companies were using things like spiral models and those kinds of things. The business community was just still doing structured. The other thing that happened in the mid 90s, which caused an enormous change for the Internet, Gui interfaces, and again, object oriented programming. What the internet and GUI interfaces did for the industry, is a change the whole focal point of software development. They changed it from internal systems. To external customers. And that was a huge change that not everybody has realizes. And those speeding up things, the change to the internet and GUI interfaces, were two of the things that kind of drove people into doing iterative development. And that became agile development.
Luke Hohmann 07:31
Got it? And I think the in terms of the influences that you list, I was writing them down. And just to reiterate, some of them we had object oriented programming, which which gave us better abstractions and better tools. We have the GUI user interface. One more thing that I'm going to add to this agenda that I think is actually quite profound was that the patterns movement started to gain steam at that same time. And I remember when I used to work for electronic data systems, we would create those large requirements documents, and what I realized was that those large requirements documents embodied a few things. There was usually a section at the beginning for vision like this is what we want to do. Then there was a section for kind of a roadmap and then there was a section for the more detailed requirements. And then of course, we would build these out. And in many times the interaction between the technical people and the business people were such that the business people would say, Well, this is kind of where we want to go. And the technical people knew that there would be change in the system. So they'd ask more questions. Well, that conversation had to be documented in such a way that the requirements grew. One of the things that I think happened was that we started to see patterns in systems that and we knew the patterns existed, but we started to document them. And so then and the My favorite example, from the meta pattern structure is data warehousing. Right? It's a common need in business to analyze our data in multiple ways. And in the 70s and 80s. Those data warehouses were bespoke, they were built one at a time, but then we had Ralph Kimball. Start to publish data warehousing patterns. And we had David Hayes publish business model patterns. And we started to see patterns and I think another enabler of what has become Agile is this idea that wait a minute, I can still have a vision and we talked about vision. I can still have a roadmap, but I don't need as many detailed requirements because I can take a pattern off the shelf and Grady Bucha has done some really interesting work here with documenting large numbers of patterns, but I can identify a pattern. You know, no one builds an ecommerce system from scratch anymore. We have patterns for that. And I think that's one of the things that really moves us into the Agile world out of the rat and Jad world or the spiral world because spiral was still in that era of a more I would say invention, which is great. That's not a criticism. But now we've got patterns and I think another enabler to the swirling set of things that enabled Agile to be what it is, is patterns. Yeah,
Jim Highsmith 10:23
and you know, the pattern movement kind of grew up on the O side of things. So people like get back and Ron Jeffries, and Chet Henderson. Hendrickson are all part of that patterns movement as well as Ward Cunningham. wiki that they use for patterns, he was kind of a patterns wiki, and then it kind of turned into an XP wiki over over time and become more and more of the catalysts for XP. And one of the things people don't realize is, is that in 2001, when the manifesto was written, we didn't have any social media to speak of. It was all conference speeches, art magazine articles, and and boards wiki was a big part of that of getting the word out about agile Oh, and patterns. So
Luke Hohmann 11:11
let's talk about that right because this evolution, this confluence of factors coming in. I think you might know that I used to be a heavy duty op guy I was a small talker, etc. So then you and some friends got together and created the Agile Manifesto, which which I actually suspect took off in ways that you might not even have imagined like, I think you might have had something bigger than you expected when it was all done.
Jim Highsmith 11:41
Yeah, I don't think anybody that was there at that meeting, all 17 of us had any idea that it was going to take off the way it did. And it's interesting because people want to go back to the manifesto, and I think it's a good source document, but they have to realize that the concepts behind the Agile Manifesto have to be kind of extended to some of the stuff that's going on today. And we can talk about that a little bit later. But
Luke Hohmann 12:08
right now, I mean, if you look at the Agile Manifesto, right, it starts with a set of four values, and then it promotes a set of principles or practices. And so let's let what some of which aspects of those values and principles do you think have stood the test of time? And which do you think might be in need of maybe a fresh coat of paint?
Jim Highsmith 12:31
Let me back up just a little. Sure. I think there's a lot of confusion in the marketplace, about the difference between methods, methodology, and mindset. And I think this is where we get so bogged down. Sometimes, methods or practices are things like test driven development stand ups, sprint planning, those are all practices, a methodology or framework and no framework has become a bad word these days, which is too bad. We can't get rid of all the words we've been using or we're not going to be left with any words to use. But methodology or framework is stringing together a bunch of practices into somewhat of a systems development lifecycle. And then a mindset is, how does your mind work? Is it A, is it a plan, do mindset or is it envision explore mindset? And we can talk about the different aspects of mindset and culture. And so what I think happens is some people think that Agile is a methodology. It really encompasses all of those things, including the mindset. There is no such thing I keep reading articles right for a while about the agile methodology there's no such thing and and methodologies can be simple or they can be complicated. And I think back about Alisha Coburn's idea of crystal methods, and he had some dimensions on his methodology. So, he taught criticality versus number of people. So, as the number of people went up the the amount of of rigor that you needed went up in the amount of documentation you went up, if you had a small team of six people doing a non life critical system that requires a different methodology. So it remains it means that you've got to design methodology to meet the criteria. Or the context of your particular problem. That's another interesting thing about the pasta. I think there are originalist and they're pragmatist. Related to the manifesto. A generated an originalist originalist says the manifesto says Software and by damn good software, the prognosis says you can play outcomes or products where software is in the manifesto. So you can that's the way you interpret it. The next thing is it can evolve from agility as a core mindset. So for example, I was involved in 2005, six and seven, with an organization called the agile project leadership network. And so it was taking the agile mindset and applying it to project management. And so we rewrote some of the values, empowering and trusting teams embracing and adapting to change, facilitating collaboration and communication. I can trace those directly back to the manifesto, but it's a different set of words. And I've seen people do this for product management and some other things. So it's extending the the intent of a manifesto into other areas. And so what I would like people to do is to realize that it's not static, it's not that it's pragmatic and it can evolve.
Luke Hohmann 15:49
Yeah, like that. And so I think that the the notion of the values and and I when I was on the board of the Agile Alliance, I used to talk about how it you have kind of layers of durability, right? The values are the more durable aspects than the practices, because we vary the practices or the principles as we need to and I also agree that that Alistair's model of the different methods and the different needs of different teams and different team sizes are paramount in terms of understanding how are we going to behave in a particular context like what is our organization? What is our team doing? And like you said, am I building life? You know, mission critical systems are life critical systems, or am I building a game and sure there's economic impact, but there's different levels. And I go ahead. One
Jim Highsmith 16:42
of the things I talked about in my project management book is what I call an exploration factor. It is a technology exploration fact that technology, but then of it, and then there's how flexible requirements are. And so an exploration factor one means it's technology that's well known. Everybody knows how to do it, and the requirements are not going to change in a number 10 The requirements are changing all the time, and I don't know what they are. And I'm using a bleeding edge sock technology. And each of those kinds of projects with different exploration factors required different kinds of methods and practices.
Luke Hohmann 17:22
Agreed so now, when you look at the impact of the principles, some of the principles seem to have spawned entire industries of platforms and tools, or you mentioned TDD, well TDD is, is there's tools that exist for TDD, like given when then in gherkin or you know cucumber, or they're like, there's actual infrastructure. So what's the and we've got some questions about AI. And we know that AI is kind of an important topic right now and we're going to cover AI a couple of different ways. But what's your take on some of the tools that have evolved from the from the innocence the guidance given or the or the inspiration given by the manifesto? And how might these tools start to continue to further evolve with AI?
Jim Highsmith 18:11
Well, I think there are two aspects of this one of what is which is how can the tools evolve? But the second one is sort of implied idea that somehow tools and frameworks are the problem, and that somehow this agile industrial complex is a problem. And I would like to say that, yes, there are some issues, but I think bashing frameworks doesn't get at the core issues that are what I call disappointments in Agile. So rather than say, success and failure, I like to say for even for a particular project, what have we accomplished and what are our disappointment rather than accelerate and fail? So I listed four things that I thought our disappointments in Agile that I could see over the years. Number one is the capability is spread too thin. And I'll go back to Jerry Weinberg's last strawberry jam, the wider you spread it, the thinner it gets. And out on the edges, it's pretty damn thin. So you have novices teaching novices about agile, which is not a not a great way to go. There's a balance between if you think about it, the core two things that came out of the Agile Manifesto meeting was that producing excellent software was one objective and building better workplaces, healthier workplaces. was another. Those were the two key things. It's like performance and people. And I think to some extent, the people side in the last 10 years or so, is we put too much emphasis on that and not enough on performance. And I'll give you an example of that in just a minute. Organization and leadership. One of the things we found is that agile teams and agile, agile groups, but in it we need the organization to be more agile in order for a software area to be more agile, and that's why we're still still working on. And then the last one is a fixed mindset. I think if you were to read Carol Dweck, book 60% of the world is fixed mindset. And 40% is is growth mindset. And that really has to do with your ability to change. And so I think those are some things that get out there. So let me let's talk a little bit about performance versus people. So performance is customer value and financial is business benefits. People is a healthy work environment. If you think about what we've been calling this sort of new modern management, we've got some names one empathetic servant, self organization, well being leadership, collaborative leadership. It doesn't say anything about getting the job done. It's about how you deal with people. And those are very necessary, but I think we've gone a little bit too far. A friend of mine who's a CIO. When he goes into a to an Agile transformation. He identifies two two kinds of people, enablers, and doers. And the enablers are everybody in the management chain including the Scrum Masters, project managers, agile coaches, people like that and the others are the people that are actually developing and delivering and you've got to have both, but I think in the Agile community, we've gotten out of whack a little bit. And in fact, I see companies that are not the that are being touted as getting rid of Agile. What they're doing is they're rebalancing the ratio of enablers and doers. And I think that's what that's happening in a lot of organizations today. And I think the other thing too, is that the balance is going towards more engineering talent and more engineers more talent, this disk density in the engineering area, and and less emphasis on the enablers, and more on those doers. Wow,
Luke Hohmann 21:58
there's a lot there. So I took I took down four notes, and I'm going to come back to them but I want to say, Jim, that I think that you're what you just said about the business side like and this for everyone listening. This is part of the reason why Jim and I are so happy to reconnect because that is the focus of our my last book with Jason Tanner, software profit streams. We are deeply concerned that the Agile community has completely shifted the emphasis in the ratio a little too much towards what you said, which is the people and environments I'd like then is not to discount that. But at the end of the day, it's a whole lot easier to pay the bonuses and have the nice work environment when the company is making a sustainable profit. And when we talk about what you just said, the business the finances, understanding value, and value and some of that was done by Tom Gill, right with language and a few other things. But, but really bringing that forward. I'm so glad you're saying this because we're in alignment with you. We believe that that one of the greatest dangers that's happening right now is that the Agile community tends to run around saying I'm going to create value. I'm going to create a value stream and I'm going to produce value and they don't define it. They don't put a number on it. They don't they don't manage it. And it's really really frustrating. But go ahead.
Jim Highsmith 23:32
Let me give you an example. One of the things my friend did was go into an organization to take a look at their Agile transformation. They had 98 developers. And he asked me the question, how many project managers do you think they had 9898 project managers for 98 developers, and what and one of the reasons for that is they were heavily siloed and they were had they had five or six projects per person. And so they needed all these project managers to manage all the dependencies between all these projects are going on and all these functional areas. So it wasn't the project managers fault. It was an organizational problem that led to that and a reasonable level. of spending. It gives us about 15% ratio of enablers to doers, that would have bet that 98 project managers would be reduced to 17.
Luke Hohmann 24:28
Right and, and those ratios we know in other parts of of management science how many people report to you and what happens when people increase that number? Many times people think it's bad things but often if you increase the number of direct reports, it's good things because it forces the leader to delegate it forces the leader to trust their people more as opposed to quote unquote, it's it's a lot easier to micromanage to people than it is to micromanage you know, 17 in two different teams when you start to let the team structures emerge. I want to go back to one more thing that you talked about and I think it's quite relevant. This this and we talked about this, you said what have we accomplished and what are some of the disappointments and I love that framing and I think it's a healthy framing. It belies your own growth mindset when you say disappointment as opposed to failure because you're looking at this from that different mindset. One of the questions that I'd like to talk about is the notion and we've seen it and I'm bringing it up because it's flying through the chat, Jim, is this notion of, of novices teaching novices or people who don't have the deeper experience and this is a tension because at one level, we do want to bring in new voices. We do want to bring in fresh blood. But at another level, there's some concern that that some of the ways in which we're we're sharing our tribal knowledge is is degrading that knowledge and I don't I don't know if you have any thoughts on that, or what might happen about that?
Jim Highsmith 26:10
Well, one of the things that I've been thinking about recently because I've also been thinking about the application of AI to management, and so that's one of the areas I've been looking at. And so to really think about capability as opposed to knowledge. And capability is equal to three things. It's equal to knowledge. So knowledge is something that AI can help or help with, right away. But the other two things it's a little fuzzier knowledge plus experience, so what experiences in your head that you can bring to add context to the knowledge that you have? And then the final one is judgment. Do you have what it takes to make judgments about what you're experiencing and what you do based on that knowledge? And what are you doing those judgments on? And are you taking taken enough? risky? Are you doing enough risky things? So that you can innovate? And it's harder to say how AI can be applied to experience and judgment. Those are some of the things that humans can do that I not yet at least has a good handle on. So it's not just gaining knowledge and that for example, I used to kind of be anti certification, where I come from certification. I've gotten two kinds of certifications, professional engineering, certification, and a CPA from accounting and those are certifications that require very extensive test experience in the job in order to get those certifications. So I don't look at the certifications these days. I look at them differently. I look at them as sort of Boy and Girl Scout get merit badges. You know you if you did this, you know you made fire you're gonna merit badge. And, and so I don't have a problem with those types of certifications, or those kinds of merit badges. But those don't give you experience or judgment. And that's what I think is missing from a lot of these novices teaching novices and the other thing too, if you take the beginner intermediate expert, you just take those three, and moving between those three you can tell map those things together. Beginners, have knowledge or gained knowledge. intermediates, have people gotta have some experience and can add that experience to that knowledge. And experts are people who can change the things because they think they know how to use practices and adapt those practices to new things. And we don't have enough time and some of these organizations to go through that intermediate and expert step. And the other thing is we don't have a good lifecycle to do that. So it's really interesting. You use agile development in order to do iterative development of products right. Shouldn't I use the same approach to use iterative development of your processes and practices and methodology?
Luke Hohmann 29:06
In general, yes. And I think the challenge on experience is that there there is a wide set of research in cognitive psychology that talks about the 10,000 hours of practice to become an expert, and the areas in which we might be able to short circuit some of that through AI. But the challenge with AI and we have an AI tool at Applied frameworks called Horizon and it's designed to help product managers and product owners and making better choices about pricing and licensing and what we found in our own use of AI and in our own AI tool, is that when you're viewing the AI as a partner in divergent thinking, it tends to work better. When you start to put too much pressure on AI systems in convergent thinking. That's when you start to get those forced hallucinations, right, the AI is going to make something up to try and, you know, adjust its algorithm. So I think we're, we're kind of it's exciting to look at the some of these opportunities and some of these gaps. And the other thing that you talked about was you you use the words knowledge, experience and judgment. And I like those terms. And, Jim, I don't know if you're aware of this, but in the world of civic education, and civic development, that that world uses the world the words knowledge, skill, and disposition. And, and it largely parallels what you were talking about. In the civic engagement world. We talk about knowledge do I know the structure and I'm going to for all of our international people, please forgive me. I'm just going to limit in time to the US but the knowledge of the US government, what's the Congress, what's the house, what's the Senate? What's the executive branch skill? Can I read a bill and understand what that Bill means to me? Is it going to raise my taxes is going to change the finances? disposition? Am I more conservative? Am I less conservative? How do I feel about certain things and is this and I agree with you that that we can definitely see the AI is helping and knowledge we can see them collaborating? With experience, right, I can start to trade my experience with the AI and in the judgment and or disposition, it starts to be less effective. So let's let's change this a little bit. I'd like to bring in something that I know is near and dear to your heart. You're leading this new reimagining agile initiative. And the first question I have is, you know, what are some of the goals that you have? And then the second question is, how did you select the individuals who are participating in it? Why should the Agile community writ large, listen to the people who are reimagining agile for others?
Jim Highsmith 32:11
Let me do the second one first. This is a group of people who got together at a kind of ad hoc last year at the annual conference in Orlando. And so it was hi blesser, who was at that point was the board chair of the Agile Alliance. Sanjeev Augustine, who's a good friend of mine, and John Kern. John had invited me to the conference to be on a panel with him about this kind of reimagining agile and I had done some work in that area. And so it's kind of a, and we got together at the conference and said, you know, this is something that we think is a good idea. Let's do something with it. So it was an ad hoc group of people. And one of the things that we've done is we've called ourselves as a launch group. We're not trying to control manage, organize anything, we're trying to give people a forum and an idea to run with it when they say how can they help? We turned that around and said, what can you do to further this idea? You know, can you have can you write a blog? Can you have a podcast? Can you have a presentation at a conference, and it asked what I, what I would deem success is to regenerate some of the enthusiasm for agility that we had in the early years. If you go back and you read the manifesto, it's got four pieces of four pieces in that manifesto. It's got the manifesto, the values, it's got a principles page. It's got a page about history. It's got a page about the authors, I guess it got six things and it's got a page where you can sign up and say, I agree with the Agile Manifesto, or I think this is bullshit. Go back, go back and read a couple of those pages from the early years. And the enthusiasm for something that's brand new comes comes across. And I'm hoping that some of that enthusiasm that we had 23 years ago can be injected into the Agile community because I think it's really important and I in getting ready for this talk. I actually came up with a new tagline okay, if you if you fail that agile, you will fail at AI. Okay, I think that's true, because AI is going to change things in ways we really don't understand and they're going to change them rapidly. And unless you have a finely tuned growth mindset and agile, adaptive mindset, you're going to get lost. So I think those two things go together and that's why I think there needs to be new enthusiasm, enthusiasm about agile and agility.
Luke Hohmann 34:55
Okay, so So, what we'll want to do is we'll want to put into the to the Webinar Notes, how do people get involved? And I don't want to go into that now because I know that that's going to change and that's going to improve so well. I had to put some links in the show notes, but I've got to ask a few tougher questions. A lot of people have made a lot of money from agile, and a lot of people are upset that they didn't make money as much as other people. So what are some of the monetary implications? Because a lot of companies, a lot of consultants, like for example, you talked about the danger of novices teaching them, but given that there's no innocence Certification Board, which you talked about, it's pretty easy for a relatively unskilled but maybe dynamic person to write a new book. And we see this all the time. Here's my new agile book, and I'm some new exciting dynamic person and I'm a good speaker, and you should follow my method. And maybe that method isn't actually very sound, but they're gonna make money. at it. So how do we deal with some of the, you know, monetary aspects about who's going to win and who's going to lose economically about if there's new reimagining agile, or this next wave of agile succeeds
Jim Highsmith 36:18
I always like to ask the question, What can people expect is going to happen is did you expect anything else is going to happen? As it became more and more popular than the tools vendors got yet and you know, people who teach workshops and it's interesting that a lot of I feel like a lot of the people who are naysayers at this point, are themselves making a lot of money out of agile, they're just doing it a different way than they say this, this group over here is doing it. And yeah, you can you can you can rail against some of these things. But what I'd like to do is to take those questions back to those root causes that I talked about earlier. And maybe it's not because the organization is making so much money at this, but they've got they've got thin instructors, teaching thinner participants and and it's something that's gone so rapidly as agile, although I don't think 23 years is all that rapidly. But you think it's been a valuable movement for over 20 years, how many other software development and or management practices have stood the test of time like that? And I think again, it's because it's rooted in a set of values. That are sort of ongoing. One of the things about the methodology and I have I bought, sold and taught methodologies all through the 80s and half of the 90s. And these week I call those the monumental methodologies of the time, when the great big books and and you know, lots of documentation and lots of forms, and I've taught all that crap for a while. But the one thing that they didn't have back then is they didn't have a set of values that were explicit. They implicit values. implicit value was documentation was always a great thing. To have because we have so much of it scooting. So that's part of the history that I think people don't recognize that there was a there was a setup. At one point that early 1990s There were over 100 vendors of computer aided software engineering tools. Right, right. Yep. And most of them went bankrupt, but some of them then became the core knowledge base of the core impetus for other kinds of tools that came on later in the in the after the turn of the decade. Yeah,
Luke Hohmann 38:39
at least. Some questions and so I'm gonna, I'm gonna close that off by saying I agree with you. I mean, I'm asking what I wanted to be was a fairly provocative question. But to the to you and me. It's like, it's not all that provocative, because it's like, yeah, what did you expect? There's a movement and there's a capitalism and there's opportunity and the other thing that I pointed out to people is when people complain about some aspect of agile, the complaining is as if the buyer or the customer was somehow stupid, meaning certifications are bad and people get certified the HR people are stupid. Well, I'm not sure that's true. And I don't think it's true. And I think that what happens is is, is the markets tend to resolve on what is appropriate, and it can take time. I mean, I also remember many, many of those case vendors in case tools, some of them were pretty sophisticated. And they came along and they left because they actually didn't solve the job in referencing jobs to be done. They didn't actually solve the job better, so they didn't last. Okay, now with that we've got about 15 minutes for questions, and I'm just going to do one real quick one. I'm gonna give a shout out to Liz Sweeney, and she says the 10,000 hours rule has been debunked. So Liz, if you're still listening, we would love as panelists. I would certainly love and I'd like to thank you for that. I'd love to see what what you can share in the chat that would help us grow from that. Because there is a maybe maybe it's maybe the new law is that there is no need for any kind of experience. You just do a Johnny Mnemonic and pump something into your brain and you're the expert. So I'd like to know, when this is. You know, there's I'd love to know for myself, and I'm sure other people would too is what's the current thinking and what's the current research on the development of expertise. But with that, Lisa, do you want to pick out a couple of questions, or do you want me to pick them out? How do we want to do this?
Lisa Castelien 40:47
I'll kick it off. And then let's see how we go. Maybe like following the answers to the questions. We'll get into more of the details and we can come up with more insights. But thank you so much, everyone for adding your questions. If you still have questions, feel free to drop them in the q&a section at the bottom of the screen. And also upvote questions, because we have 15 minutes left and there's already a bunch of them in there. So we want to make sure that we cover the most popular ones. So let's start with a question from Greg. He asks, even after all these years, I see large struggles working with organizations that require a fixed scope and a forecast date for delivery. even mentioning no estimates, angers those executives, how big of an obstacle Do you see this mindset to agility? How do you address this dissonance?
Jim Highsmith 41:38
One of the things that back in the mid 2000s I started hearing a lot from agile teams. And this is just one aspect of that. What I got what I heard from agile teams is they want us to be agile and flexible and adaptable. But they also want us to meet the scope scheduling and cost deadline for plans. And if you deviate from the plan by 10% that somehow you fail that used to be the old mindset. So you had a disconnect between the teams who are trying to do Agile and the frontline managers who are trying to manage to the old style. So one of the things I developed was called the Agile a triangle with value at the top quality on one side and constraints on the other and the constraints were scope scheduling cost. I've always been able to do an agile project to a fixed time schedule. If you'll allow me or enabled me to coordinate or collaborate with management to get some things adjusted. You can't fix everything. And so it's it's both a management challenge and a team challenge because teams they don't they don't want any kind of accountability. They just want to be able to, you know, though accountability in terms of the traditional way mode. I was in Munich, Germany, years ago, in front of about 18 software development managers and these were second level managers for the big electronics firm in Germany. And they said our Scrum Master says we can't tell them how long it's going to take or how much it's going to cost or when we're going to be through and I said wasn't what did you think? They asked me what I thought about that. I said, That's bullshit. You know, you have fiduciary responsibilities to your organization. You need to know some of those kinds of things. What you've got to be able to do you got to be able to negotiate some flexibility somewhere, if you've got to be flexible and change direction that you need to change, then you're going to have to have some flexibility in your measurement approaches. And so I think those are those are things that the management and leadership changes as well as changes at the team level.
Luke Hohmann 43:52
I'm going to add Jim that, to that that notion of you know, how what are the responsibilities is I am decidedly not a fan of the no estimates movement and because I agree with you that there's certain responsibilities that we have in in an agile to create economic estimates. I think part of the challenges is that we have not broadened the training to include how to estimate so I, I would I would offer and I love the fact that people are sharing articles and books, this is really exciting. But I would offer the book, How to measure anything, as a classic book that helps people learn how to estimate more effectively, how to put probabilities and ranges on their estimates so that we can estimate both the economic value of something right what you know, I want to bring a new product to market Okay, well, what's the possible profit margin? What how would I price it? What's the value of that market? And from there, I can derive Well, here's pretty much my estimate range that I can so you know, I can invest in building that product and then go back and forth with our development functions and say, can you build this thing software or hardware or software, you know, hardware enabled by software? Can you build this thing in this set of ranges so that the to end up being a successful outcome? So I I fully agree and and the maddening thing is, it's not that hard to get vastly better at estimating and vastly better at making good economic choices on both the top side and the cost side. So
Jim Highsmith 45:33
the other thing about agile The only thing about agile development is that you can incrementally get value and cost. And so you have to continue to ask the question, is it worth 100% of the value for 100% of the cost? Or could I get 90% of the value for 80% of the cost? And you can make those kinds of trade offs in Agile that you couldn't in previous ways of going about projects. Right. Please
Luke Hohmann 45:57
pick another one for us. We got a few. A few more minutes here.
Lisa Castelien 45:59
Got a few more minutes in either we have a lot of questions to go through. Next up we have one from anonymous. So give your thoughts on what's the next step after agile or Scrum? What do you feel is the future path of a scrum master in the next phase of agile movement?
Jim Highsmith 46:18
Good Well, good. A lot of trouble for this one. I think we're gonna go number one, I think we're gonna go more towards not frameworks or methodologies to buy off the off of a vendor, but those that you put together yourself my whole approach to coming up with a methodology, which is a series of practices that go across the lifecycle is to start with the simplest thing possible, and then add stuff to it as you need it. Whereas the big framework approach is to give you all of this stuff, and then you're supposed to take away stuff that you need for your particular project. I've always found that taken away was was really difficult. So I start small and build up. And I think that's the way to do methodology in terms of Scrum Master. I'll put all of these Scrum Masters, project managers and agile coaches in the same then you've got to increase your technical knowledge period. That no longer can you can you subtract survive just on working with people and coaching the people side of it, you've got to be able to coach the performance side of it. And coaching the performance side of it means that you've got to have technical knowledge. So for example, how many of you how many SCRUM masters project managers out there have actually tried some of the AI tools and are playing around with them and experimenting and doing that kind of learning? Because I think the the, the idea of a career path is over. You have an obstacle course you've got to traverse. So it goes from computer career path to obstacle course. And you've got to be able to transition that obstacle course. into how things are gonna bubble.
Luke Hohmann 48:03
Alright, listen, let's let's grab another one.
Lisa Castelien 48:05
Let's keep going. Thanks so much, Jim. Next one, what are your views on agile teams working in the context of waterfall businesses and how do you advocate for spreading agile ways? of working throughout the entire business?
Jim Highsmith 48:19
To Well, if you're trying to do in a waterfall company, you're in trouble. You know, change. You got to change the mindset. to more of a growth mindset in the management side as well as the technical side. Otherwise, you're just going to be isolated projects. And there were plenty of those in the beginning of agile that dealt with a lot of teams. I was I was working with Mike Cohn one time and talking about what I call the growth team period. of agile development where you just had these teams in organizations that were trying to Agile, and Mike went into one organization and said, Oh, yeah, we got three three agile teams, and like found four and the manager didn't even know they had a fourth agile team. And so that's the kind of thing that we were dealing with 20 years ago, still dealing with it today. And it's a very difficult situation.
Luke Hohmann 49:17
I would add that in Be patient, one of the largest failure modes that I experienced and the clients that we work with who are trying to continue down their path of Agile is that people get upset with the rate of change or they get impatient in some capacity. And if Agile is working in a small way in the company, and there's this larger context of less agility eventually the the organization is going to start to recognize for its own health, that it needs to start adopting some agile practices and people in the chat might say, Oh, you don't understand. That leader. Is is holding us back. There's some senior leader well I was working with an organization that had the same fixed mindset CEO for 30 years, and that person finally retired and they put it in a new CEO and change started to happen. So I think the time horizon can be a very on unfairly limiting to what can happen. And like Jim said, agile is only been around quote, unquote, 23 years, that's not very long. And there are CEOs who've been around longer than 23 years. So letting you know being consistent taking the wins. You know, nurturing that that small, agile flame of goodness, maintaining positivity. Finding those the strategy of small wins by Karl Weick is really fundamental and building on wins.
Jim Highsmith 50:59
In the culture can go the other way. Contact with several organizations, where they changed the CIO from a growth mindset to a fixed mindset. And it really undid all the Agile stuff within the organization. So I've seen that happen to
Luke Hohmann 51:14
exactly maybe we do one more. And then what I would let people know is that we'll find ways to grab the questions and provide some thoughts on them through applied frameworks. Jim, and I may or may Jimmy do that. I know I will commit to that. But let's get one more. Yeah.
Lisa Castelien 51:33
So I'm just taking a look because I see that there's a question that's been voted by Amy on the Agile certifications, but I think we spoke we touched on that a little bit. So go to the next one up. Why do you think there seems to be an industry move to eliminate the scrum master role and organizations?
Jim Highsmith 51:54
I don't think there's a move to to eliminate it. I think there's a move to change the ratio of Scrum Masters to engineers. And I think it's gone too far the other way. So it's a rebalancing, more than more than getting rid of people. And so sometimes that rebalancing, you know, leads to some job loss. But I think one of the things that again, one of the things that a scrum master can do to enhance their scalability within their organization is to become more technically competent as well as the other the other scrum practices competent.
Luke Hohmann 52:34
Well, I would also, I want to list that that, that if you go to the scrum guide, and we allow ourselves to limit ourselves to the scrum guide and the definition of Scrum Master right among the things the scrum guide says is the Scrum Masters accountable for establishing establishing Scrum and as defined in the scrum guide. And they do this by helping everyone understand scrum theory and practice both within the scrum team and the organization. Well, if you just take that first sentence, sometimes the Scrum Masters that I've worked with who were highly effective, they did feel their job as I'm going to get this organization stood up on Scrum and I'm going to create a self sustaining entity and therefore Quantico, they don't need me, or they need me much less like imagine you had poor dental health, and you went to the dentist for several months to get your help and learn new habits. Well, then you might need to go to the dentist every you know, four months. So you can you can really see the role of the scrum master, as you know, am I really empowering the organization and therefore maybe I'm not needed in a healthy sense, or am I really creating this kind of weird dependency because I'm a scrum master and I like my job and I don't want to lose my job. And I think that's really a really fundamental framing of like, how do you as a scrum master, view your job and your responsibility relative to the organization you're working for?
Lisa Castelien 54:11
Okay. Thanks so much, Luke. And Jim. I know that we have a bunch more questions in q&a, but with two minutes left, I want to make sure that we have time to wrap up the session properly. Jim and Luke, thank you so much for the valuable conversation. I don't know if you have been keeping an eye on the chat. Look, I know you have because I saw you posting in there as well. But Jim, just so you know, people have loved listening to your conversation and your valuable insights, the metaphors, particularly were quite enthusiastically received by our audience. So thanks, everyone, for joining us today. As Luke said, we'll try our very best to answer the questions that are still in q&a and share them together with the record today's session. If you want to review today's sessions you can do so through the recording again, thank you so much for joining LinkedIn, thanks so much for hosting and having us today and taking the time out of your days. For those of you celebrating Valentine's have a great Valentine's for those of you who aren't celebrating, have a great rest of your day. It's just another when Wednesday after all, and thanks so much and looking forward to seeing you all on our next edition. Thanks so much. Thanks.
Jim Highsmith 55:25
Thank you Excellent. Thanks.
Lisa Castelien 55:29
Bye, everyone. Thank you Bye
Jim Highsmith is an industry advisor, having retired as Executive Consultant at ThoughtWorks, Inc. in 2021. Prior to Thoughtworks, he was Director of Cutter Consortium’s Agile Project Management practice. He has nearly 60 years’ experience as an IT manager, product manager, project manager, consultant, software developer, and storyteller. Jim has been a leader in the agile software development community for the past three decades.
Jim is the author of Wild West to Agile, Addison Wesley (2023), EDGE: Value-driven digital transformation, Addison-Wesley 2020; Adaptive Leadership: Accelerating Enterprise Agility (2014), Agile Project Management: Creating Innovative Products (2009), Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (2000) and winner of the prestigious Jolt Award, and Agile Software Development Ecosystems, (2002). Jim is the recipient of the 2005 international Stevens Award for outstanding contributions to systems development.
Jim is a coauthor of the Agile Manifesto, a founding member of The Agile Alliance, co-author of the Declaration of Interdependence for project leaders, and co-founder and first president of the Agile Leadership Network. Jim consulted with Information Technology organizations and software companies worldwide.