Mike Leber (00:00.91)
Here we go. Our guest today is Josh Kerievsky, and those who are a little bit involved with Agile probably know Josh. He's been probably one of the first people in the Agile movement, and I think he was fortunate enough that he was involved when it was not called yet Agile, but was these, I don't know, dark years of lightweight methods, but which were probably...

very exciting and yeah, it's amazing having Josh today here. Josh, maybe you wanna introduce yourself a little bit about your background and what you're doing, what's been.

Joshua Kerievsky (00:42.777)
Yeah, thank you so much Mike and Harold for having me on the show. I'm the CEO of Industrial Logic. I've been running this company for about 27 years now. I'm a second generation software person so my father got into the profession many years back, back in the 60s. So I grew up around software and computers. I've been really just a...

in love with agility, in love with high performance teams and how to make work more joyful and more fun and productive, helping create great products for users. And as a person who loves agility, I've found over the time that it applies to much more than just the IT field or software field. Its agility is...

something that is useful in all aspects of life and many professions and athletes and all kinds of human endeavors benefit from agility.

Mike Leber (01:49.902)
So it's been a while you've been involved with all of this, right? And we're going to touch base a couple of different points, but let us maybe start with a little bit of a provocative one in the beginning, looking at the current state of being. Is Agile dead?

Joshua Kerievsky (02:10.981)
I love that. Great. Yes, a great question. So I think the answer is no, it's not. I think it really much depends upon your definition of Agile. And I think this is where the question is relevant because for many people, Agile is a noun. Agile is a thing. They think of Agile as some framework or...

Mike Leber (02:12.605)
Surprise question.

Joshua Kerievsky (02:39.489)
on collection of frameworks or processes that exist out there, and it's a thing that you do. And maybe such a thing could die, yes. But I don't think of Agile as a thing. I don't think of it as a noun. Agile is an adjective, an Agile dancer, an Agile lawyer, an Agile team. It's an adjective, the manifesto for Agile software development. Agile is an adjective there.

You can't kill the adjective and the adjective will never, it's not going to die, it's not going to be removed from dictionaries. The concept of agility is here to stay and if anything I think we're at the beginning, the early days still of understanding agility and applying it to our world. I think 20 years is nothing. It's nothing. If you study Stoicism for example and you look at the lives of the Stoics and you see, you know,

the decades and centuries that passed and how different people took Stoicism and kept going with it and kept refining it and trying to help others learn it. You're talking a very long period of time. Twenty years is nothing. So to me, yeah, it's an adjective and we're in the early days of agility.

Mike Leber (03:59.798)
So I think that points already to your latest book, The Joy of Agility, which came out this year, right? Beginning of this year, summer, first quarter. And I think it is important to clarify and discuss the meaning of words, as you just pointed out. The interesting bit might be, and I think that's what we also want to touch.

Joshua Kerievsky (04:09.915)
Yes.

Mike Leber (04:28.482)
today a little bit, if you approach an organization, a client organization or, you know, somebody who's interested in this stuff or challenged, how would you, how would you, you know, start a conversation about the words with them? Like, you know, the boardroom and five years into agile, lots of money, not enough results and a lot of frustration. I'm not sure if it's easy going to start like, you know,

The meaning of the words just got it wrong. How can you turn this into a conversation where people, you know, regain focus or whatever.

Joshua Kerievsky (05:08.249)
Yeah, well first off, I would help them understand the definition of the word and that it applies to every aspect of an organization. It's not an IT thing, as it often is thought of. Right, I mean, and just people will, they'll say design thinking, they'll say DevOps, they'll say Agile, they'll say, if you see what I mean, it's like these are different things. They're all different things. You got your, you know, your lean startup, your design.

If agility means the ready ability to move with quick, easy grace, or having a quick, resourceful and adaptable character, I mean, wouldn't we want that in, I don't know, people operations or HR, wouldn't we want that in sales and marketing to be quick, resourceful and adaptable? Wouldn't we want that in the leadership team? Wouldn't we want that everywhere? It's not a thing. It's an adjective. It's a way of being.

So I would start in the boardroom, I'd start by clarifying that and basically helping the organization to understand, so where are we not quick? Where are we, for example, hurrying or rushing? Where are we slow? In the sense of a bad slow, where people are pissed off because there's all these delays. Where are we not resourceful and maybe resentful? Where are we not adapting fast enough?

So how can we look at those areas of the organization and improve them? And that's where I would start the conversation. And then you are going to get down to specifics at some point. You're going to start saying, well, we have three different tools to manage requirements. Maybe we ought to get it down to one, and maybe that will simplify some things. I mean, there's always going to be nuts and bolts emanating out of these more high-level concepts like the definition of agility. Yes. But I start there.

Mike Leber (07:02.094)
Right. I remember myself the late 90s when I got involved in with these things in very small environments to be honest. And today we see huge initiatives and there's a lot of challenges in there. So in the 90s I could relate to the word joy. So my question would be how did you bring this word in here?

What makes it joyful?

Joshua Kerievsky (07:34.521)
Mm-hmm. Yeah, well, first of all, I am a fan of Richard Sheraton's works, you know, Joy Inc. and Chief Joy Officer. Richard's great. However, I have to be completely honest is that those words from his book did not really influence me. What influenced me was a book called Joy of Cooking. And that was a book that my parents had and they often were opening it up and using it. And so it was around the house. And I...

wanted to talk, I also felt a lot of despair over where Agile has gone, to the point where people won't even use the word anymore. The movement has come and it's become very commercialized. There's something we would call the Agile industrial complex. All these consultancies and tool makers all buying for your dollar. That is unfortunate and a lot of.

certifications and just a whole industry of money making that is maybe it has good intentions but a lot of times I think it's just focused on making money. There's a bit of despair about that. It's sad. It's very sad to see where that's gone. Agile in name only. We see that all the time. Cargocult Agile. There's all kinds of names for it.

I was talking earlier before we started with Harold about how you could spend a lot of time finding problems with the quote unquote Agile movement. So joy was the opposite of that. Joy was to say let's focus in on joyful agility. Like where has it been like really wonderful in terms of the results it produced, in terms of the joy it brought to the people. Could I share my favorite

you know, agility leading to joyful results and hope that people would look at those examples and say, wow, I want to be more like that. And that was the idea.

Harald Wild (09:44.809)
Well, to add to that, I've always asked myself, why do people in companies always have to work harder and walk the extra mile, which is somehow negative rhetoric. Why can't they just have more joy in working and get involved more by that fact? And so there is the question.

What are many organizations doing wrong when embarking on their journeys? Or what are they usually doing right when they start the journey?

Joshua Kerievsky (10:18.865)
Well, I think a lot of organizations are already maxed out. They're already, even before they start an agile journey, they're trying to do so much. And that sort of feels professional. So we have to have ambitious goals and we have to go for a lot of things and we have everyone's gotta be super busy. But that doesn't necessarily lead to great results. The most intelligent companies, they say no more often. They...

They stop we have a phrase we say stop starting start finishing So they're much better at saying no to new ideas even if they're great ideas they say no to them because they're like well, let's finish what we started and Let's not have too many things happening at once Right because then people are running around we see all the time. It's like, you know, you meet a person They're like well, I'm a quarter percent on this thing and half or half, you know 50% on this other thing and then another 25% on this other thing

And I'm context switching all week long. Frankly, I'm not very productive because I'm context switching constantly, right? So, you know, when you're attempting to become more agile and you're already in a context of being overwhelmed with work or just, you know, the soil is not ripe for agility in that situation. You really have to address that first.

Mike Leber (11:48.066)
before your book came out, in the years before, you actually brought up another concept with modern Agile, which became pretty popular. I know a lot of people who are carrying the sticker on their notebook and it's in lots of places. And I think it's comparable to what Alistair Coburn did with the Heart of Agile, just a different angle perspective.

Joshua Kerievsky (12:06.5)
Yes.

Mike Leber (12:15.134)
I think Alistair's was later, at least in terms of publication, I'm not sure. But it doesn't matter anyway. But the point, you know, again, talking about organizations...

A lot of organizations are pursuing complicated frameworks. Sometimes it looks like the larger, the better, because hopefully it includes everything and we don't miss anything. So the question would be, how can an organization just, you know, ignore the big frameworks and turn to modern agile in terms of principles and be guided by them? I mean, what do you think is a missing link or could help?

Joshua Kerievsky (12:58.625)
Yeah, I mean, I think you're right. People are afraid of missing something. They're afraid of, okay, we're going about this, but we don't have all of the details we need. So the large frameworks, if they provide more and more and more detail, then all the better. We feel safer. Whereas if you just start with a bunch of principles, it feels almost like it's nothing. There's nothing there. One of the reasons I wrote the book, not the only reason, but...

A reason was people said, well, the four principles of modern Agile are great, but we need more. So it's like, OK, great. I'll tell you a bunch of stories of examples of it. And the book and the modern Agile are very closely aligned. The principle-based approach to agility, I think, leads to better outcomes in the long term, starting with principles.

But using those principles, right? And in the book, I call them mantras, but they're effectively the same thing. They're these cherished notions that you use for decision-making and for everyday work, right? They're top of mind, right? Unfortunately, most large corporations don't really, they're not aware of the simpler approaches like this. So, you know, they gravitate towards these large frameworks.

I don't know how to stop that. It's kind of like sugar. People love sugar. They're gonna keep eating sugar. I found ultimately that in life that processed sugar is not very good for me. My body just doesn't react to it well. And it's taken me many years to get to that realization, but I find other things that I enjoy eating and I don't have to have sugar. So it's a journey. I think we have to be louder maybe about.

the benefits of principle-based agility and get more folks to be aware of it. So there's probably room for improvement there in terms of simply getting the word out. And then there's the connection between the principles and what you're actually going to do on the ground. And the large frameworks are trying to pull together all the different potential methods out there. There's nothing terribly wrong with that.

Joshua Kerievsky (15:18.713)
A lot of people will say, well, we're doing this framework, but we don't like these parts, but we do like those parts. So we're kind of really just picking the parts we like, you know, and that that's fine. I mean, that's if that if that brings beneficial results, great. I don't I'm not the policeman for what frameworks to use or not use. I just think ultimately, you have to have your head pointed in the right direction, which is, you know, are we simplifying work? Are we making work easier?

quicker and more graceful. Those words in the definitions of the word Agile, the adjective Agile, are very important to be focusing on. That's what I've noticed.

Mike Leber (16:02.562)
Well I'm wondering...

Harald Wild (16:02.593)
So the essence is that you use tools and methods when the need is created and not because a framework dictates you to. And create value from these approaches, so a more empirical way to watch what your needs are and then use tools and methods to accomplish things.

Joshua Kerievsky (16:26.701)
Yeah, I mean, you could look at the practices we tend to use. Well, I'll point back. I could point them to the exact mantras or principles that we hold clear, that are dear to us, whether it's make safety a prerequisite. In modern agile, we say make safety a prerequisite, enjoy agility. I'm using Deming's mantra, which is drive out fear. So what practices are we using when we do ensemble programming?

Well, we're actually creating a whole bunch of safety there. And it's intentional, very intentional. We're looking at safety through test-driven development or ways of having automated testing in a test suite. That's providing a great deal of safety. We are endeavoring to be psychologically safe, always hard, you're never done with that work, but we try, we try. So we're focusing on safety. So those practices on the ground.

are directly related to a principle or a mantra. And so, you know, they're there to help you implement the principle or mantra. That's what they're doing. And if they're not helping, then you get rid of them and you try something else.

Mike Leber (17:40.718)
But that brings me to one more point. Fear and safety are obviously not related to practices, right? Some people might say that's related to emotions. I'm wondering, is there any framework, any agile framework out there that is including a module which is about emotional intelligence? Or even going further, relationship intelligence?

Joshua Kerievsky (17:51.534)
Yes.

Joshua Kerievsky (17:54.882)
Mm-hmm.

Mike Leber (18:08.362)
I'm not sure, I'm just asking if you know any or...

Joshua Kerievsky (18:08.4)
Mm-hmm.

Joshua Kerievsky (18:11.685)
I mean, you know, I don't know if there's any that's doing it explicitly, right? Talking about that stuff, I think, you know, anyone that gets involved in psychological safety tends to get involved in emotional intelligence. In my book, Joy of Agility, there is a mantra called be balanced and graceful. And this is probably one of the most challenging mantras in the entire book. Because

Well, as we talk about in the book, to be balanced doesn't mean just physical balance. It means mental balance, emotional balance. It balance can be applied to the makeup of the team. It can be applied to things like, okay, do we have the right balance of new development work and maintenance? Do we have the right balance of validating requirements and implementing requirements? Balance is huge. If you focus on it, if you make balance a first class thing.

it can be a big part of your improvement strategy. And I think, emotional, so coming to work and having balance in your emotions, so you're not angry or you're able to manage that better, it's very, very important to high performance. John Wooden, the famous coach from UCLA Bruins, would say, you know, he'd want his players to be mentally, emotionally, and physically balanced.

Mike Leber (19:37.282)
Awesome. And you know, that was the point. I mean, getting back to what you said earlier before talking with the boardroom about, you know, what they're missing, what they might instead longing for is probably not new artifacts or different frameworks. It's probably about the question, how can we meet each other in a context where we talk open.

open words where we, you know, open up and just talk about potentially fear. I mean, you, you said it before. Most organizations are driven by fear, but that's also involves the boardroom. Um, recession ahead, you know, problems and all of this stuff. Maybe it's no coincidence that there is this first agile value, people first, right? I mean, I usually read it sequentially. Um, and that makes me always saying, and that's the first one that might drive the others.

Joshua Kerievsky (20:18.257)
That's right.

Mike Leber (20:35.224)
Not sure.

Joshua Kerievsky (20:35.937)
Absolutely, people first. And you can't underestimate the importance of people feeling safe in order to be high-performing. If they're not feeling safe, they're not going to be at their highest performing levels. When they were building the Bay Bridge in the San Francisco Bay Area, right, the Bay Bridge was a normal kind of construction project back then. That was the 1930s. And there were no nets. There was very little safety.

People were dying. You know, back then for every million dollars you asked that you would spend, you'd lose a life. You know, so a project could be 30, $40 million and you know, there's 30 or 40 people dying. That was the average. And when they actually built the Golden Gate Bridge, they did things very differently. They invested in all kinds of safety equipment. They were innovative. They took mining helmets and they applied them to the bridge construction. They did...

goggles for the glare that you'd experience. There was a tremendous amount of focus on safety, and it actually helped in the project timeline in terms of staying true to what they wanted to get done in all the years of building that thing, especially this wonderful net they put underneath the bridge so if people fell, they got blasted by some wind, and they'd fall, they were safe. This allowed them to work faster because they weren't afraid of losing their lives.

Now that's an extreme example, of course, right? You know, you're not gonna fear for your life on a software project maybe, but when you're afraid of touching the code, when you're afraid of making a change, it's gonna slow you down quite a bit. So we have to remove fear. And that's an ongoing practice of how do you do that.

Harald Wild (22:27.029)
Well, that's an interesting point because in modern agile it's like in a nutshell, make people awesome, make safety a prequisite, experiment, learn rapidly and deliver value continuously. And the part with the safety, and I think it's very important for people high in the hierarchy to support exactly that because...

Joshua Kerievsky (22:40.155)
Yes.

Harald Wild (22:52.949)
The higher you are in the hierarchy, the faster you can destroy safe environments. And how important do you think that is and how is your experience in real life when it comes to companies and especially the higher hierarchies in understanding these principles?

Joshua Kerievsky (22:57.806)
Absolutely.

Joshua Kerievsky (23:11.237)
Well, I think it comes, it starts with the word safety, because I think my approach in life tends to be that I am fairly certain that when I use a word, I am using it, I have a different definition of other people. So even the word safety can mean something completely different, you have to understand, you're almost like, it's like when you're speaking, if you don't define your words, you're not speaking the same language.

One person will think of safety as like, they'll say something like a sailboat was not meant to be safely anchored in the harbor. All right, sailboat's meant to be out there experiencing the, you know, the ocean or whatever it is, the body of water. So that's a negative view of safety in a way, right? It's like safety is this thing you should avoid. Go out there and dare, you know, be brave.

We're not talking about that. We're not talking about that at all, right? It's not safe to not take risks, right? Not taking risks is unsafe. You've got to take risks. Hopefully they're just safe risks. They're not crazy risks that you could lose your life or an organization could be destroyed. So you have to understand, you have to get to a clearer, a shared understanding of what safety means when you talk about make safety a prerequisite.

What we're talking about here mostly with that is harmful things that actually hurt your productivity, hurt your ability to do great work to make people awesome. Those are the kind of things we have to get rid of in the workplace. There's even a famous book that was written in the 1990s called Driving Fear Out of the Workplace. And it's something I mentioned in my book along with a bunch of other great books on...

fear and removing fear. There's Linda Rising's book, Fearless Change, and of course the Fearless Organization by Amy Edmondson. There's a lot that's been written on this and it requires to me studying it. I'm not sure I answered your question though, Harold, because you asked about the boardroom, I think.

Harald Wild (25:26.497)
Well, not only the boardroom. I mean, it's like, it depends on how many hierarchies there are in a company, but the higher levels of hierarchy, which are more powerful to just push or destroy things with very little effort. And so they have to be very cautious what is being done, or they have to have a great understanding of exactly what has to be done to create safe.

create safe environments and for safer environments.

Joshua Kerievsky (26:01.209)
Yeah, and I think a big issue there is that people don't know each other's challenges, right? Someone at an executive level might not be communicating the challenges they're facing. So if they're pushing stuff downstream, people don't understand why. And that could be because the executive hasn't really explained how they're afraid. What are they afraid of? It could be they're afraid of their boss firing them, right?

Fear can be everywhere in an organization and I think it helps to talk about it. I think it helps to reveal it and make it transparent and then focus on how to get rid of that fear. That's what Deming said is the manager's job is to drive out fear because that fear hurts productivity. Fear makes life miserable and it's not joyful at all. So that's the kind of fear we got to get rid of and it's hard work. There aren't a lot of...

extremely high performing organizations. There's a reason for it because it's hard. All right, it's not easy to get this all right.

Harald Wild (27:07.213)
Well, there's another part of this because we have developed many metrics to measure performance of people and teams, but very few metrics to measure emotional intelligence and maybe communication skills. So what is measured is just performance and not even outcome, output most of the times. And so how...

important do you think is the measuring of the metrics in that case?

Joshua Kerievsky (27:38.233)
Yeah, it's a great point. I mean, we've been working with Amy Edmondson's organization to become certified providers of her model, which is a way of, it's called a psych safety index. And so you basically ask people questions and walk them through this. And it's at least better than what we've had in the past, because it's a way to at least get a temperature gauge for how psychologically safe is an environment.

That also points to the emotional safety to some extent, not enough. But I think you're absolutely right. It's very important to know what's going on there emotionally. And that's the best managers seem to do a bunch of one on ones. They're constantly checking in on their people and seeing how things are going. When people feel cared for, it's very different experience, I think, in terms of an organization than when they just feel like a tool.

or they're just managed with these metrics that just treat them as if they're not a living being who has hopes and dreams and challenges in life and a family or people to take care of and stuff like that. There's all those human factors that are really important.

Mike Leber (29:03.291)
Large organizations also have an issue regarding probably architecture. I mean, relating to what we just said, I always love to talk about either an organization as an organism, as a living organism, or as a structure which is super complicated. And as a consequence, I think...

We run our organization super proficiently, but we lack to focus on what's really needed by whom, respectively customers, right? And that's probably another one. I mean, is what we already said, what you already mentioned a way out to actually refocus, to relearn whom we are serving and what they need?

Joshua Kerievsky (29:40.676)
Right.

Mike Leber (29:56.33)
Again, get into relationships with customers.

Joshua Kerievsky (29:59.825)
I mean, I believe that the companies that are most customer centric are the safest companies out there because the customers love them and they're looking after those customers. Now if you treat your employees horribly in order to make your customers feel looked after and safe and all that, that's a problem too because you won't really be able to do it effectively if you have unhappy staff. So you really need both. This is why modern agile doesn't say make users awesome.

or make customers awesome, it says make people awesome, because it's the constant focus on how can we make life better and better and better for both those we serve and those we work with. So that's the hard part. And you're right, Mike, it's about understanding their needs, understanding what they need and what would be beneficial. Now, sometimes people don't know what they need.

I mean, Henry Ford's famous for saying if I asked people what they wanted, they'd say a faster horse. They would never have said an automobile. So you need a balance there between what people say they need and what you perceive as a potential game changing capability or product or service. That's also there.

Mike Leber (31:23.85)
Right. So it's, but it's still, the better I understand our, the mission, um, the more I'll probably try to optimize the organization for effectiveness and not just for running an efficient machine, right. And, and finally set up structures which are just there for themselves.

Joshua Kerievsky (31:40.494)
Yeah.

Joshua Kerievsky (31:44.677)
That's right, but I think it also comes down to human. How good are we at human communication? Tom DiMarco, the famous guru of our field, he wrote at one point, we are in the human communication business, most of us. We're not in the high tech business. People writing compilers might be in the high tech business. People producing LLMs and the AI models are maybe in the high tech business. We're mostly in the human communication business. We're, you know.

Mike Leber (31:49.262)
Mm-hmm.

Mike Leber (32:00.428)
Mm-hmm.

Joshua Kerievsky (32:12.197)
producing systems and things that help communicate with people and How good are we at that right? There was a senior architect or I forget is I don't know his exact role at Spotify who basically Got the board to agree to a very large refactoring if you will because he explained that the once People could sign up for Spotify on a mobile app That they were going to spike in

have a huge spike in signups and that the infrastructure was not prepared for this. So now was the time to prepare for it before the spike, before that went live. Let's do it now. Let's pay the price now and re-architect and make things solid so that when we start to see exponential growth, it won't be a problem for us. And they agreed. However, that person was a good communicator. That person gave a compelling message to the board and the board agreed.

Not everyone does that, right? Some people may just bitch and moan about how we never clean up our technical debt, but they're not effective in terms of selling it to the organization. And so, I think there's, you mentioned architecture, I just made me think in terms of sometimes some re-architecture is really needed, and it's needed even to help the customers and or the organization thrive.

Well, great, make a great case for it. Be resourceful about how you show the need for it so that you can sell it.

Mike Leber (33:55.946)
Let's have a look at the consultant side. One of our recent guests was Jim Highsmith and as we recognize through the reading and when you listen to Jim, you both share a lot of history together, work together in the early days, had a lot of experiences in new territories of this whole movement, larger organizations.

wrote about in his latest book, Wild West to Agile, which I can only recommend everybody to read, where he mentions the skill needed, and he refers to you and how you collaborated to mix and mingle different approaches, to not just follow one guidebook, here's crumb, here's XP, or is even safe, and you just follow this, is extremely high. And...

So what do you think would consultants and or coaches need today or should or could focus on in order to, you know, focus on the right skills and build up their right skills in this direction.

Joshua Kerievsky (35:08.237)
Yeah, I mean, I think it's a great question. I think if you're going to be really good at something, you have to devote yourself to it. You have to be a scholar. That means you have to study, and you have to find your mentors, and find those classic books to read. And really, it's not about certifications. It's really about becoming a master of your craft.

And that requires tremendous love of it. If you love it, you'll be naturally drawn to studying it in all aspects, right? So I think, to me, the people that really are amazing are the ones that just get deeply into it. They're constantly asking questions, they're looking for mentors, they're reading books, they're going to conferences to learn. To me, that's the important thing. And then you need to develop.

you know, a certain kind of bullshit detector. You have to be able to spot the bullshit. You have to be able to spot the things that are agile in name only, or that are fancy new little things that aren't necessarily so great. We're very careful at my company, Industrial Logic, to we'll try new things, but we won't talk about them for even years until we've seen them actually work while in multiple contexts.

and then we would be behind those things. Not to say like, we used certain things in agile methods for years until we decided let's get rid of them. Let's try not using them and see what happens. Let's try going lighter weight, going back to the lightweight methods, right? What can we drop and still be successful? So, I guess there's no easy answer. It's just a lot of study. There's important works, very good. I mean,

Jim's book is fantastic, Wild West to Agile, because it really shows the evolution of our thinking over all the many decades. And it's an invaluable way to understand how the, at least the software industry has evolved and where it might be going. But you can't forget the basics. A lot of times, there's just some basics, like fast feedback in Agile, right?

Joshua Kerievsky (37:31.749)
the ability to get feedback really fast, to learn fast. That's a concept that's timeless. And those are the types of things you gotta just try to get better and better at. So.

Mike Leber (37:47.758)
In these early days, I think the term agile coach was not born yet, or it was not, you know, populated as much. And I have a stance in coaching and I really like it, but sometimes we're currently living in tough times because we currently hear, okay, a lot of coaches are being, you know, laid off in larger organizations and everything. And

At the same time, I sometimes think about the phrase being over-coached and under-led. So what's your take on agile coaching? Again, related to where we just came from, saying how can we help our clients in the best possible ways?

Joshua Kerievsky (38:27.429)
Mm-hmm.

Joshua Kerievsky (38:34.933)
Right. Well, pretty much for anything you're asking me today, by the way, there's a story in my book. So Joy of Agility has a story about a world famous surgeon and famous author now Atul Gawande. He's famous for numerous books, including The Checklist Manifesto and various others. At some point he did a TED Talk, which was about whether you have a coach.

And he basically said, well, athletes have coaches. Why don't professionals in other industries have coaches? And his point was that you will actually improve if you have a coach. So he himself as a surgeon, a world famous surgeon, no less, found an old professor of his that was really brilliant and asked the professor to come and observe him in the surgery room. And...

the this particular fellow was able to just notice a few things that a tool could have done better which again would lead to better results for his patients right now imagine the humility that you have to have to do that you're a world famous surgeon you're still getting a coach um i've sought out coaches throughout my career gotten a lot of help from coaches um i play tennis i have a tennis coach and uh get really uh excited and happy when i go there because

I learned how to improve. I very much believe in coaching. And so whether it's called Agile coaching, lean coaching, you name it, I don't care. If you don't have some mentors who are helping you, you're probably missing out. So whether there's a fad of Capital One got rid of all their Agile coaching, I don't really care. I really couldn't care less. You've got to find those people who can bring you to higher levels, who can help you, inspire you.

to get to higher levels of performance. And if you're interested in high performance, you'll get a coach.

Mike Leber (40:36.962)
So that also sounds like for the coaches, and I know a lot of them are now going for professional, you know, credentials like ICF and everything, which is good too. But probably be courageous as a coach also to think about where and how you create value, right? And how you can help people just to move forward and to see more. And

that doesn't necessarily probably have to relate to a certain discipline of coaching or anything like.

Joshua Kerievsky (41:04.431)
Yeah.

Joshua Kerievsky (41:10.669)
Yeah, I mean, the label of Agile Coach might be, you know, Agile has baggage. People will say Agile has baggage. To me, they're referring to the noun Agile. They're not referring to the adjective because I think the adjective is here to stay for a long time. So I think I saw someone recently change their title to Continuous Improvement Coach. And that's fine too. You know, it's... You have to deal with what you're dealt.

Whatever the world deals you, you have to adapt to it, I guess. I'm not shying away from the word agile at all, but others are, and that's okay. I think at the end of the day, it is about the results. It also comes down to how can you visualize your expertise? How can you make... It's not so much about... Some people visualize their expertise with certifications, like all these letters behind their name.

That doesn't impress me. What impresses me are stories, stories of where you were involved in something and made a huge difference. That's impressive to me. I might want to learn more about your stories. I met a coach down in New Zealand. He was working with a team of programmers who write software for bank tellers, the people you interact with at the bank when you walk into a branch of a bank and you...

And this is a bank I was at, right? I was doing an assessment. And he discovered with his new team he had inherited, right? He discovered that the programmers never, ever, ever spent time with the actual bank tellers. One guy had been there for many, many years and he always worked from specifications, but had never actually met a bank teller. But he'd been writing bank teller software for a long time.

And this is another story in the book, right? So what this coach did was to bring the developers together with the bank tellers, and the developers got to observe the bank tellers doing their job. And sure enough, one morning a customer walks in and says, I would like to deposit this particular money here to my vacation account. And the bank teller said, I don't have nicknames for the accounts.

Joshua Kerievsky (43:31.833)
I need to know the number for the account. And the person, the customer said, well, the website lets me put a nickname to my account. Why don't you have that? I'm like, well, I'm sorry, I don't. So what's the number of the account? I need to know the number or I can't deposit your money. The programmers watched this particular scenario happen real unfold and they said, wait a minute. Give us a couple of days and we can like put the nickname on your particular screen so you won't have this horrible interaction.

And they collaborated with the bank tellers. And then within a very short period of time, they had the nicknames of the accounts on the bank teller computers. They solved the problem. And that was joyful. That was joyful for the bank tellers, joyful for the developers, joyful for the coach. That's an example of agility. Those stories to me are really what says to me, oh, that coach that I talked to, who did that?

He gets it. I don't care what letters he has under that back behind his name. I want to know what he's done. And that to me is, is proof that he understands the need for close collaboration, people and, you know, and interactions and stuff.

Harald Wild (44:51.073)
What do you think is the importance for handling that stuff? I mean, you have acquired the toolbox in the years and years of working in a company, and then there is change, and maybe your toolbox doesn't work like before anymore, and you have to acquire new tools. And I don't think frameworks, but like tools you use in your daily work. And there are some of them that might be...

not really present. I mean professional tools like how do you manage projects or that's present most of the times but how do you create safe environments for teams? How do you create trust or support trust in teams? How do you create transparency? Those are tools or maybe tools you need that many people do not have in companies because well they didn't need to in the first place.

many people who had them were successful with them because they could use them. What is your opinion on that shift of tools that you have to have when you switch the system of a company from maybe a pretty linear to an agile approach?

Joshua Kerievsky (46:08.533)
I mean, I think emotions are always going to win out over tools, right? If the emotions are out of balance or people are unhappy or afraid, then the tools are, you know, they're not going to be that helpful to you. You know, you'll be using them, but you're not going to have high performance. So high performance really requires everyone being kind of, you know.

very excited and focused and happy and understanding the aligned on what you're trying to accomplish not feeling too rushed constantly rushing feeling like someone has their back you know in terms of safety so that if they're you know sick or something or whatever people can they're not going to get in trouble or you know there's just a lot of the emotional factors that lead to high performance and I don't I think you're right we don't teach them.

very well, like there's training classes for tools, but are there training classes for emotional intelligence and things like that? Certainly there are people that teach that stuff. But I think you're right, is that in the world of work, for the most part, that is ignored and people focus more on the nuts and bolts and mechanical side rather than on the mental and emotional side. It's very much the same in the medical field.

The medical industry treats most of us like a car. Oh, this is wearing out, we need to do an operation. They don't look at the emotional or mental side of things. That's a whole topic on its own.

Harald Wild (47:49.953)
You know, I was always thinking that it should be more easy to reduce pressure when it comes to not having to work when you're sick, when you're in Germany or Austria because we have like 26 consecutive days of sick leave where you just get paid. And after that, your health insurance covers like 60% of your salary. But most of the times...

That's not what I experience in companies. So there's a difference in what could be and what really is, because maybe the pressure is not really coming from that side. I don't know. I don't know how it's for you, Mike, in Austria. What do you think about that? But it should be more easy to create these environments when you don't have to fear losing your money.

Mike Leber (48:47.67)
Yeah. One more question about the old and new times. Because in the early days, extreme programming, and I think you've been one of the early promoters and specialists with your company, you've been into this as a consulting group, I think extreme programming, supporting others and helping them to basically grow the competence and everything.

was the most prominent framework probably, or don't even know if we called it framework, but thing in the late 90s. Nowadays, it's the opposite. Not many people talk about extreme programming anymore. And most talk about Scrum. And we know the difference, right? Because extreme programming wasn't going into more details and being way more concrete, versus Scrum is very, you know, you could say shallow.

by definition, but my question here is what might we have lost by scrum taking over or extreme programming basically having been forgotten?

Joshua Kerievsky (49:59.829)
I mean, I think we lost a lot. I think the consultants behind the different methods really wanted to beat each other, really wanted to win. And unfortunately, Scrum did something that was just sort of, to me, kind of horrible, which was to introduce the two-day certified Scrum Master course. That was the beginning of Scrum Master.

a very, very bad decision and it has trickled, it has created a monster. It has created a lot of problems. Now many would disagree with me and say, well, wait a minute, Agile got popular because of that. You know, I mean, that's how it, you know, has crossed the chasm, if you will. But what we see crossing the chasm is very shallow, very...

approach to agility which is being thrown out by a lot of organizations. They're basically saying don't even say the word agile anymore around here. And to me it much of it points back to this kind of crazy decision to have a two-day class in which nobody has to take a test, nobody has to prove skills, they simply attend the class and they are a certified Scrum Master. It is such bullshit it's beyond words.

It's this reason that I don't particularly like, there's a lot of things I don't like about Scrum, but I really don't like the leadership that in the Scrum community, and unfortunately that thirst for certifications, kind of like the way children want sugar. There was a brief period where I rented out a part of my office to an architect, and his son would come along.

There were these sugar cubes, cubes of sugar that you put in your coffee or whatever. I don't know why, but this father used to give his son an entire, just a sugar cube. Just he'd open his mouth and stick the sugar cube in the kid's mouth. I was like, oh my God, that's just wild. But this is what the industry wants. They want sugar. They want the quick fix, you know, and Scrum was providing that. So I do think we lost a lot.

Mike Leber (51:58.939)
Mm-hmm.

Joshua Kerievsky (52:25.517)
I do think that the hard parts of agility are always going to be a minority of people that want to do that. Right? I mean, I play tennis. I can't tell you how many people, they stay at the same level for decades. They don't take lessons. They don't improve. They're just having fun, of course, but they're not improving. They're barely improving.

There are various people that will say, nope, I want more than that. I want to actually learn how to hit the ball properly. And I want to get better and better and better. So I think even in most industries, and especially with Agile, it's hard work to keep learning. You have to read about lean. If you've been studying Agile stuff, great. Read about lean. If you've been studying lean, read about sports and learn from amazing coaches. I've learned so much more from.

John Wooden about agility than anyone else, right? And this is a basketball player and coach. And I feel like I've learned more about agility from him than any other source. I think, you know, I don't want to belabor the problems of Scrum and the problems of that stuff. I think it's unfortunate, but again, the real joy comes from diving in, being a scholar, learning.

the great stuff that's out there so you can experience the joy of agility. That to me is where it's at.

Mike Leber (53:57.454)
Right. Now, I can think about two things primarily when I think about XP, which we might have lost the one, I still remember this role, you know, customer as part of the team. So this proximity, where some companies now call it zero distance to customer versus scrum where, you know, like a developer team might just say, we don't want to talk to anybody outside the organization.

The other one, which I would rather like to emphasize is building a real product and focusing on tech competency, craftsmanship. And I mean, we're talking about AI a lot these days and, you know, technology is becoming commodity, but on the other hand, it's more complex than they were before. A lot of people say every company nowadays is a software company. So the question is...

What are we missing here? I mean, how are today's software developers lacking, I don't know, skill, education, probably time. That's probably a thing, right? Give them the time, as we said before, give them the right environment. But, you know, it's a little bit of a catch-22 game here. What's the way out to increase the competency here?

Joshua Kerievsky (55:19.313)
I mean, again, I...

Yeah, I mean, I think software is a tough field because you could be like, you know, when a basketball team is very successful because they win games, right. And they win a lot of games and you'll get, you know, the Steph Curry's of the Golden State Warriors being the, you know, scoring the most three pointers. It's easy to see quality. It's not so easy to see quality in something like software, right. You could have a process and you could have a visitor go and visit that team.

or teams and see what they're doing and not be able to see how awesome it is. They literally can't even see it. I call it invisible excellence because they're not able to see, hey, look, they're doing micro commits. They're getting feedback super fast. They're invalidating features before they build them. They're mob programming, dealing with knowledge silos so perfectly that they don't even exist. There are no knowledge silos. They can take...

someone who's never ever programmed in React Native, bring them onto an ensemble, and within 30 minutes, that person has pushed code to production. Like, phenomenal. And like, I think it's invisible to a lot of folks, they can't see it, they don't know what great it looks like. So they'll be working in their normal Git flow approach, and this is how it's done. I'm building my component on the front end, and I'm gonna wait for you to finish on the back end, and then eventually we're gonna like...

hook it up together and they're gonna have problems, we're gonna fix the problems, and then we're gonna go live. And like, no, that's very slow, you know? There's a lot of, but they don't see it. So they think that's normal, this is fine. Whereas a lot of us in the XP community or lean community are always looking out to get rid of the bottlenecks, get rid of the waste, look for ways to make it better and better and better. And we're open-minded to try new stuff, right? Like...

Joshua Kerievsky (57:17.833)
There was a time we didn't do continuous deployment at Industrial Logic. And then around 2007, I learned about it. I was like, wow, this is phenomenal. There was a guy named Timothy Fitz from the company that Eric Reese started, IMVU, and he gave a speech called Doing the Impossible 50 Times a Day. And that was about deploying to production 50 times per day to production with millions of users and doing it safely.

talk in 2007 blew my mind. And by 2009, Industrial Logic was doing it. We didn't even have to. We had an e-learning system with, we didn't have millions of users, we had hundreds of users. And however, we wanted the experience under our belts of doing it and understanding it. And so we pushed ourselves to do continuous deployment and that was incredible, absolutely incredible. So it's, do you have that thirst for

continuous improvement, right? I think that brings me joy to continuously improve. I don't like to sit around with problems that fester, right, that don't get solved. That's to me not what good engineering's all about.

Mike Leber (58:27.918)
Mm.

Mike Leber (58:33.902)
Short side note, you probably read the publication by McKinsey about how to measure individual programmer performance. What's your thought about this? I couldn't resist to ask.

Joshua Kerievsky (58:46.885)
Oh, it was just so ridiculously bad that I, a lot of people gave it attention and I've just been trying to focus on other things that I've already started. So I didn't give it much attention. It reminded me of, there was a book that I studied very extensively in the early 1990s. It might've been actually 1990 or 1991, but it was called Code Complete.

and by McConnell, Steve McConnell. And he has these little icons in the side of each page. And there was this icon. Well, there was a phrase, and it was W-I-S-C, which stood for, why isn't Sam coding? And basically, the idea was why.

If Sam's not at the keyboard coding, then something's wrong. And I was pointing out how ridiculous this was because a lot of software development is just thinking about the design, thinking about what the users need, communicating with people. It's not always coding to be an effective programmer. So it just brought me back so many decades to that book and the WISC acronym, why isn't Sam coding? It just made me laugh. But it's pathetic and it's really sad that

Ignorance like that spreads around and hopefully, you know, not too many companies just pick that up and run with it because it's very sad. There's a lot of ignorance in the software field. It's a tremendous amount of ignorance, right? I think Federal Express, you know, you've probably heard of Federal Express, you know, for them time is the enemy. They want to get you your package as quickly as possible. Time is the enemy. In the software field, ignorance is the enemy.

Mike Leber (01:00:28.846)
Right, right.

Joshua Kerievsky (01:00:44.497)
And it is a persistent enemy. It is constantly rearing its head. And it is just a, it's a very difficult enemy to fight because ignorance pops up in all sorts of different ways. And, you know, we see some frameworks out there that I think are causing a lot of damage and they're very popular. We're constantly battling ignorance in the software field.

Mike Leber (01:01:12.51)
I think I have the book somewhere even. You just mentioned, I think it was by Microsoft Press, right? As far as I remember, I have it somewhere in my shelves, but I would have to check it out in the early days.

Joshua Kerievsky (01:01:18.477)
Yes, yes, code complete, correct. That's right, very early, the early days, yeah. Well, for some, for some early days with the 60s or 70s or earlier.

Harald Wild (01:01:32.481)
Well, being successful is about individuals, but also, but even more about teams and having successful teams and amazing teams. And we've talked about how to create environments where teams can be successful, but what are, in your opinion, the ingredients that you need to mature amazing teams?

Joshua Kerievsky (01:01:58.221)
Well, I think first of all, it really helps to know what are we trying to achieve, right? So there's a practice called chartering, which really gets into clarifying, you know, what are we looking to do here and why are we looking to do it and what would be some criteria to prove we're successful and who is a part of this engagement, right? Who's part of this initiative? What's our community? What are our community agreements? How do we wanna work together? So some clarity around

you know, vision, mission, objectives, community, working agreements, that's always very, very beneficial to a team. But the other major thing is, I believe that it's very, very helpful to give the people who are doing the work the respect of not solutioning for them. In other words, giving them the problem to solve, and whatever...

whatever safeguards are needed there, but let them help come up with the solutions rather than just giving them the solutions. Now we're not talking about a trivial case, like okay, here's a report with five columns, we're adding two more. There's no solutioning there, okay? It's just two more columns. But we know for more advanced things, there's many different ways to approach something. And so if you just come in and tell people, here's what I want, there's no opportunity there to discover maybe

a more efficient way to do it or something that would be sufficiently good for the customer but it would take a fraction of the time. I call this bargain hunting. Bargain hunting is where the team gets together, they talk about what the problems are that we're trying to solve and then they bargain hunt to find potential solutions. Maybe options. Here's an option that's expensive, here's an option that's cheap, here's an option that's the middle of the road.

Just as we have options on the vehicles we purchase, right? You want options and the team can create those options. So I'm not a big fan of like the roles of like, I'm the product owner, I tell you what to do. I know that's a misunderstanding of the product owner role, but it's often implemented that way, right? You know, I tell you what to do. You're the bricklayer, you do the work of laying the bricks. That's often how it gets translated in reality. And unfortunately, that's not proper teamwork. So...

Joshua Kerievsky (01:04:21.817)
In the best teams, I believe you're helping people to invite people to be part of the creation process, to think, to not just be in their one role, but to be wearing numerous hats. And creating an environment that makes that possible is really special. And then of course there's helping people to improve, right? So finding ways so that junior folks can rapidly improve.

by working together with senior folks. To me, that's another very important part of a great teamwork. And then there's effective retrospectives, right? Which are, I just was, I'm assessing the team right now, and they've said, our retrospectives are, they run, they go like this. People say, here's what we worked on, here's what we wish we had, and that's about it. But there's really no like, what are we gonna improve?

What are we going to improve? Who's going to take on that improvement? How are we going to make time for that improvement? That doesn't happen. And so to me, those are very ineffective retrospectives. Yeah.

Harald Wild (01:05:32.137)
Yeah, these are approaches which, I mean, some of them are like two decades old. And you said a pretty interesting thing in the beginning of the podcast episode that transforming a whole business or worldwide business structures, two decades is nothing. And that's a pretty interesting perspective. But what

What do you think, how far have we come in the industry and what is the future potential of agility or agile approaches?

Joshua Kerievsky (01:06:07.653)
I mean, I think the challenge is for the people that really understand and love agility to help more and more folks to appreciate it. Sorry. That's a test of an emergency system.

Joshua Kerievsky (01:06:32.841)
to the National Wireless Emergency Alert System.

Harald Wild (01:06:36.425)
Yeah, we had that like two weeks ago. It was the same.

Joshua Kerievsky (01:06:41.093)
Well, we can always edit that out, I suppose. Sure, yeah, let me ask that question again.

Harald Wild (01:06:43.549)
Yeah, maybe you're just so over.

Harald Wild (01:06:49.417)
No, I mean, it just cut the answer in. Or should I?

Joshua Kerievsky (01:06:52.501)
Okay, yeah. Yeah, just remind me of the question, sorry.

Harald Wild (01:06:57.341)
that the approaches are like two decades old and how far have we come in the industry and what is the future potential of agility?

Joshua Kerievsky (01:07:04.017)
Mm-hmm.

Right. Yeah, so the industry, I like when I say that the Agile industry is really in its early days, to me that brings me joy because it says, there's still people that will create things that are useful. There are people that can be new leaders of this movement. It is not dying and it is not like, something where all of the great ideas have already been established. I think there's plenty.

that we can do to make this more understandable and easier for people to adopt in many industries, right? Not just in the software industry. It's the job of leaders to fix problems. And if the Agile industrial complex has created a problem, then great, let's have leaders step up to help solve that problem rather than abandoning the word Agile and, hey, starting a new movement called Nimble.

Let's be nimble. It's like, okay, same idea, different name. That's not necessarily the right solution either. Nimble can become, there can be a nimble industrial complex. At the end of the day, leaders help to solve problems. I think agility as an adjective, that move from noun to adjective, I think is very important. I'd love to see more and more people.

Adopt it. I'd love us to have a common understanding of the word agile. We have these agile conferences We use the word agile all the time. We don't share a common understanding of the word It would be wonderful if we could do that, you know, that's why I've pointed to the dictionary Definition it happens to be the Merriam-Webster dictionary a definition that I like But you know, that would be an amazing thing in the future if this people understood what the word meant I think that could really help free us

Joshua Kerievsky (01:08:58.225)
from this connection to Agile equals that framework or this framework or doing things as rituals and roles. It's not about rituals and roles. Agility is something you can see with your own eyes when you see people being agile. Like I watch tennis and there's the professional tennis players and suddenly they're going one direction and they gotta immediately go the different direction and adapt to something that was unexpected.

There's a famous, if you watch the story about the Serena and Venus Williams, the movie that was out there, King Richard, their father used to give them balls that were dead. So you have a whole bunch of balls and you're hitting balls to your daughters. But occasionally there'd be some balls that had very little air and like that was to help them adapt. An unexpected event, oh, that ball doesn't have much of a bounce. There's a little bit of a bounce, but not much.

Boy, I gotta get be ready for that. I gotta be poised to deal with that situation. That's fantastic training to adapt quickly, right? So, we have a long way to go in terms of like, are our organizations spending time learning how to adapt quickly to situations? Are they resilient organizations? Resilience engineering is another field that's making huge strides in terms of industrial safety.

you can bring a lot of that knowledge into your agile implementation. The book mentions the resilience engineering field and folks who are prominent in that field. So yeah, I think the future can be exciting for agility. We just have to continue to see it as a open playground where there's a lot more to be done and not a closed system that it's already come and gone.

Mike Leber (01:10:55.786)
I think that was an amazing conversation. We're coming close to the end of the episode. Final question, if you say, we just began. What's next on your side, Josh, except the day-to-day consulting work, but you know, you published the book this year and what are you working on? What can we hear from you next about?

Joshua Kerievsky (01:11:23.277)
Yeah, I mean, I basically, I'm interested in helping more people to become scholars. So there's a bit of a book I wrote back in the late 90s, early 2000s about study groups, and I'm hoping to resurrect that and get that out there. Because when I first started in the field of software development, pretty quickly in, I created a study group to study design patterns, which was, you know, I felt...

a book that had great wisdom in it about object-oriented software development. But that opened a community to me and it led to many other studies of other literature. I just think that if we're going to become great in our fields, we have to be scholars. And how do you do that? So this book is about one way to approach becoming a professional scholar, if you will. Not a scientific scholar, but having a group of people you study with where you're constantly improving by studying.

Great, great stuff. That's one thing. I've been toying with the idea of putting out a Modern Agile book because so many people really like Modern Agile. So it's very related to Joy of Agility, but I may do that. We'll see. You know, writing books is a lot of work, but it's something that if it can help people, all the better. I often think about writing little books about things that I don't see enough out there, like bargain hunting.

Bargain hunting has been so valuable in my career. There's a phrase in the manifesto which says, maximize the amount of work not done. And bargain hunting helps us do that all the time, but it's almost invisible. I don't see it on most teams that I encounter. So it feels like writing something about that might be helpful. Basically, I'm just trying to find the spots that are... Well, one more thing, which is...

Mike Leber (01:12:58.446)
Hmm

Joshua Kerievsky (01:13:18.833)
I would, if I had all the time in the world, I would love to help people become better consumers of agility. In other words, why is it that certain frameworks are treated like sugar and everyone just, the whole industry just adopts them and a lot of us are just like, what are you doing? Like, why are you adopting that?

Joshua Kerievsky (01:13:48.473)
the nonsense out there. How could you be a better consumer of agile methods, of agile approaches? That would be wonderful to do too. Yeah, those are some of my thoughts. But it's the book. Partly, too, is I really, I've worked my butt off on that book. And it is packed with wisdom. Not my own. It's a lot of stories from other people, some of my stories. But.

If more people read it, I think the world would be a better place.

Mike Leber (01:14:22.238)
I'll definitely add a recommendation, I mean a link to the book itself and hope to see a lot more talks from your side at conferences, events about it. But that sounds like an awesome journey and all the best for whatever is coming this year and especially next year for you.

Joshua Kerievsky (01:14:31.473)
Thank you.

Joshua Kerievsky (01:14:42.253)
Thank you, Mike. Thank you, Harold. Yeah, it's great chatting with you.

Mike Leber (01:14:47.51)
Right, it was awesome having you.

Harald Wild (01:14:47.837)
Thank you Joshua that you have taken the time and have brought so many insights with you. It was a really interesting talk and I'm looking forward to what's coming next.

Mike Leber (01:15:01.538)
Thank you and take care.

Joshua Kerievsky (01:15:02.705)
Thank you so much.