Joshua Kerievsky is the CEO of the agile consultancy Industrial Logic. For decades, he has been helping companies like Google, Ford, and other Fortune 500 firms build better products and lead more fulfilling lives.
To share these insights with a broader audience, he wrote The Joy of Agility, a book recommended by Marty Cagan to all product professionals and beyond. Its mission is to challenge the common perception that Agile is just a set of rules or a product management methodology. In reality, Agile is more than that—it helps us adapt gracefully to a fast-changing world.
In this episode, we explore various aspects of agile mindset, from its current state and organizational challenges to practical strategies for development, team dynamics, and learning, ending with insights on overcoming resistance and understanding financial impacts.
What is Agile today?
Yuriy, Co-founder and CEO of Cieden: Joshua, you are an expert in Agile and change, and you’ve worked in software development forever, like a veteran who has worked with huge companies on Wall Street, training engineers in some of the biggest companies in the world, like Google and Ford. So we see that current IT technology is changing. You have a lot of AI coming, and the speed is increasing every year. So do you think that Agile is still the same, or do we have to reinvent it?
Joshua Kerievsky, Book Author, Founder of Industrial Logic: I think our understanding of Agile needs to mature and change over time. I think it's easy to think you understand Agile, but if you're actually really truthful with yourself, and you look at your own actions, how agile are you? And the more I look at myself, I see plenty of room for improvement. It's not easy being agile. It requires a mindset that is very quick to adapt to changes. And when changes happen, a lot of us don't adapt quickly. You know, I'm a huge tennis nut, and I look at the best tennis players in the world. They are working really hard off the court to be agile on the court, which means there's a lot of preparation, a lot of flexibility, strength training, and mental training. And it all goes towards asking, "Can we be agile on the court when we're having a bad day? Can I adapt my game quickly to deal with the problems I'm running into, whether it's with the opponent, the weather, or my injuries, very rapidly?" Novak Djokovic, who's one of the best players of all time, has said, 'Champions are the ones that adapt the quickest.’ It's the same in business, and the same mostly in life. You've got to be able to adapt quickly. And that's not easy.
Yuriy: Yeah, I guess that's one of the best ideas—to check what smart people are doing. Usually, the smartest people are in business, so they invent lots of processes to help businesses stay accountable and adapt. And you should try to implement a similar process in your personal life. We, in our family, run retrospectives sometimes just to analyze how our previous week or month went and also have accountability sessions. Because if you're not accountable to yourself, it's not good. But if you have family members who can give you feedback, that's much easier.
Joshua: That's fantastic. I love it. Good for you.
The C-level agility gap
Yuriy: I did some research and found a report from a British consultancy. It’s The State of Agile Culture in 2023. They interviewed more than a thousand practitioners. What they found is that top management usually thinks everything is great with the agility of their organization. For example, 97% of C-level executives say they are good role models for Agile, but only 2% of their employees agree. Additionally, 70% of employees think that their organization is not ready for changes and a rapidly changing environment. There are lots of similar numbers. I don't know how scientific this research is, but what are your thoughts on that? Do you think that's reality? And why do different people in organizations have different opinions about the agility of their organization?
Joshua: I think, first of all, we're still in the early days of the Agile movement. It’s the early, early days. You could say two decades have passed—doesn't matter. We’re still in the early days. CEOs and executives know very little about agility. They think Agile is just something the IT department does, some methodology. That’s what they think. That is a really immature view of agility. They have no idea that the most important agility is organizational agility—the ability of the company to react to changes rapidly and gracefully. So, that would put them in the early days by thinking that Agile is going well. The methodology we’re using? Who cares about methodologies? Is the organization agile? Is our team agile? Are our departments agile? And that’s a high bar. It’s not easy to be agile, right? There’s a lot of preparation, a lot of stretching, flexibility, and strength training—metaphorically speaking—for teams, divisions, or organizations. But the benefits are very, very important for businesses.
Assessing your organization’s agility
Yuriy: How would you evaluate a new team if you had to check and give them feedback? What is the actual state of agility there, and what could be improved? Because I think lots of our viewers or listeners would want to know—even me—like, how agile is my organization? Because when I read this report, I also think, ‘Okay, I am also the kind of C-level manager who thinks the organization is pretty agile.’ But how do I actually know that we are?
Joshua: Well, most organizations, unfortunately, are stuck in the game of building components. If you’re talking about the software industry, they’re component teams building separate components, and there are project managers who have to scatter the work out to individuals who build components and then gather it back together to try to integrate them all late in the game. This is a very slow and difficult way to approach software development. It pushes the risks off into the future, and then they become more problematic. So, fundamentals of how we work in an agile way are mostly in the minority. A fundamental agile concept is evolutionary design. It’s basically starting with a walking skeleton of the thing you’re building, whether it’s a feature or a whole system. And we don’t really see that widely adopted. But we do see component teams. So, for a lot of companies, they already have an organizational structure. They already have a management structure. They have a structure. Agile comes along, and they say, "Great, okay, so now we’re gonna sprint every two weeks, and we’re gonna have standup meetings. And what else does it tell us to do? Cross-functional teams? No, no, that’s too much. We’re not gonna do those. That’s crazy." But we’ll do the basics of Scrum. The results aren’t too great. And that’s what we see when we go to consultancy. We go to most organizations; they’re either doing Scrum or SAFe, and it’s usually not delivering great value.
Mastering agile in the discovery phase
Yuriy: Yeah, and there is also lots of imbalance I see in the industry. We have clients who come to us, and they are stuck in the discovery phase. Their discovery lasts like half a year or longer, and they can’t start development because they still don’t understand what they have to build, how it would work, or what kind of technologies they will use. And there are other organizations that come with almost fully implemented software, and they say, ‘Okay, now we need some help with design because we showed this to our users, and they don’t understand the software at all. Do they need it, and how do they use it?’ So, how do you find the balance—neither doing too much discovery nor too little?
Joshua: Yeah, I mean, I think it’s a really important question. There’s a mantra in Joy of Agility called “be balanced and graceful.” And ultimately, that comes from the fact that you cannot be quick if you’re not balanced. So, to be balanced, you need to look at what needs to be in balance. And yes, discovery and delivery need to be in balance. How much time are you spending quickly learning what is necessary to build and what isn’t? How much time are you spending on that? And how many experiments are you doing to validate that cheaply and quickly? Eric Ries would call it capital-efficient experimentation. It’s quick and it’s cheap. And you do it so that you learn what not to build. You learn what is really critical here. Some companies also just put out experiments rapidly where they want to see if people click. Is it of interest? So, before building a feature, they might put in some fake stuff, or they might show it to only a few users of the system to see if they will actually use this. Is this of interest to them? And get data quickly before making a big decision to invest in some set of features or capability. So, getting better at learning faster is really important to being more agile.
Yuriy: That’s interesting because when you’re a startup, you want to be quick, but usually, you hurry and make a lot of mistakes. You need to do a lot of discovery, but you have no money and no time because of competition. You have to just try to build something. But then, when you’re a huge company with lots of people and lots of resources, you have time for discovery, but it’s too late because it’s too hard to change your product. And there are situations where huge products are not changing for years, and it requires harsh management decisions just to push the company to change because the company itself will not change at all. They will just try to optimize stuff.
Market share vs. Product excellence: What's more important?
Joshua: Yeah, and there are other things. Like, a lot of people in the software industry—I love them, but they don't know a lot about business. So in business, things happen differently than in software engineering. Sometimes in business, you have to basically capture market share. There’s a big bank in Norway that wanted to be the source for electronic payments. Right. So, on mobile payments, you have a mobile phone, and you want to pay someone with your phone. They wanted to basically be the provider for the entire nation of Norway for that. Well, guess what? There were some fast-moving startups that started taking over in that space. Right. And the bank was like, “No, no, no, this is no good. We have to squash them. We have to gain the market share, and we have to do it as rapidly as possible.” They did not have great engineers in their company. They didn't have awesome, skilled software practitioners who do test-driven development, continuous integration, and trunk-based development. They relied on outsourced development companies with big names that are global. But they just said, “Great, let's just throw something together and then market the living heck out of it. Market, market, market. It’s a huge marketing budget and okay software.” They ended up having to rewrite a lot of that software. But because of the marketing—they blasted the marketing out there—they became the standard. They got all the market share for these mobile electronic payments. That's a business story. It’s not so much about the choice of how to engineer; it's about gaining market share and leading a market.
Being quick without rushing
Yuriy: Yeah, hopefully, soon we will have more of that education as part of technical education. People will need to understand more about architecture and about business solutions. Do you think agility is like an all-star? You can’t be 100% happy with how agile you are. Or is there such a thing as too much agility? Because for some markets, for some industries, for some companies, it's more harmful when you are too adaptive to everything that changes every year, for example, and not standing on your beliefs and your strategy.
Joshua: Well, I think you can be reactive where you're reacting way too fast. Sometimes we've done some interviews with our customers about our website at Industrial Logic. And then we'll get one interview, and they’ll say, “I don't like this.” And then all of a sudden, people will be like, “Let’s change that.” And sometimes we're like, “It is a good point. However, what about what other people said? Did anyone else point that out? Is this a pattern, or is this just one person's opinion?” And so you could be too reactive. I wouldn't call that being adaptive. I’d call that rushing—hurrying and rushing.
When to push and when to recharge
Yuriy: You have a nice thought about fear, that it’s not good for software development. But we know of lots of cases when big companies were managed by fear, stress, and deadlines, and they got results. For example, Ben Horowitz in his book The Hard Thing About Hard Things said that he asked his team to work without weekends for half a year or something like that because they were going to go out of business if they did not do so. Elon Musk likes to put this kind of pressure on people to work hard till deadlines because companies like Tesla or SpaceX might be going out of business. We had similar stories from Jeff Bezos, who is also trying to build a culture of ‘We are a startup. It is the first day; we can't be relaxed,’ and other stuff too. So, in general, how do you find the balance?
Joshua: Yeah, I look at it as, you know, basically finding the right balance is the most important thing. And it's very contextual. So, I worked last weekend, all weekend. We also had people come over and had a nice dinner party, but I worked a lot last weekend. And one or two other colleagues did that with me. They also worked last weekend. And it was for something where we’re trying to win some new business from a company. And it was justified. We felt fine about it. And I said, “Hey, take some time off during the week. Since we worked weekend days, let’s take some time off and get some balance there.” Now, we don’t do that very often. I think we’d get burned out if we did that all the time. It’s basically very contextual. And I would imagine that the people who were working six months for Horowitz probably had stock options or something like that, where they had skin in the game in terms of putting in those hours and sacrificing family time or time with friends. So, you know, and if it lasted forever, it would obviously fail pretty miserably. So, it needs to be in balance. But I would never say something as bold as, “We never, ever, ever work one weekend. We never work overtime.” That’s inflexible, right? There are times when you have to flex a little bit, and then account for it, get the balance back, take some time off, and recharge. I think recharging is hugely underrated, and that we need more time recharging. We get some of our best ideas away from work. So, if you’re talking about being efficient, being in front of your computer all the time is actually not too efficient. You need to get away—go canoeing, go hiking, go visit some cities, get your brain off of work—and you might end up with some excellent ideas when you return. It’s again one big experiment as to what works well.
How agility spreads in teams
Yuriy: When you build a team, do you think you need people with different levels of agility that will balance the team, or do you want to hire as agile people as possible?
Joshua: I mean, I think Agile can be unlearned. So, I think as long as there are a few people who understand it really well on a team, then it will spread, especially if they’re working collaboratively. If they’re working in silos, not so much. But if they are working collaboratively, the agility will spread. I would love for more people to really study the principles of agility rather than the methodologies. Following a method is not necessarily going to get you where you want to be. Especially because most people don't even understand why they are following this method. They don't understand the need for it. So, the principles really get closer to the needs, in my opinion.
The code quality crisis in AI-generated software
Yuriy: How do you think software development will change in the next decade? We have lots of bold statements that in a year, AI will write all the software. There will be more consultancy work, perhaps, because now software as a service is common, but in the future, hopefully, lots of companies will be able to afford writing similar software for themselves—maybe more customized software. How is that going to influence development in general, and how do we all need to adapt to this future?
Joshua: I think AI will help in some regards. I also think it will hurt. I think there'll be too much AI-generated code that's going to be in need of fixing. And you can ask AI to fix it too, but you're not necessarily going to get simple design and the kind of deep thought that goes into what's really needed here. What do we need to produce? What do we not need to produce? AI is in a bubble right now, but I think AI will be a permanent member of the software toolchain. It will be a useful tool and probably get more useful over time as it matures. But we have to be aware that AI has learned from bad code. There's not a lot of awesome, simply written, beautiful code out there. So, garbage in, garbage out happens all the time. You have to know what good code is. Unfortunately, that's a minority of people that really know that stuff—people who have really been scholars and studied what excellent software design is. So, I worry a little bit about the quality of the AI-generated results.
The acceleration of development
Yuriy: I think we all can agree that development is going faster and faster. The time you had to spend writing a CRM system 20 years ago and now—it's a different story. Maybe it’s 10 times faster now. And with how the industry evolves, the speed will continue to increase. Maybe not 10 times, but maybe three times faster. And we can say that, okay, now it's so fast, so we are agile because we are developing systems that used to take a year, now in three months, for example. But what does that mean for teams, for developers who will need to switch to a new project every few months? Maybe because there's nothing to do there for so long. You don't need a team of 20 people—maybe five people would be enough.
Joshua: I mean, team size is always an interesting discussion too, because I'd rather have five very, very experienced engineers building something than 20 somewhat inexperienced engineers. So I always find the size of teams to be an interesting topic. But I really believe that our future will be better if more and more people become scholars of software development and really study how to do it well. Right now, we have too much of a herd mentality—people just following the herd. You know, these PRs and branches and all this stuff that real experts don't do. They do trunk-based development. They do continuous integration. They approach software development as a balance of validating whether something works and writing code. So, it's the balance. You're constantly checking to see, "Is it working?" You're not just writing code and throwing it over to QA people to validate. It's a daily, minute-by-minute thing. And I think that we're missing that right now. So I'd love to see a resurgence of interest in extreme programming and the kind of awesome stuff that happens in that kind of environment. Because XPers continue to do XP. There are no XPers I know of who stop doing it willingly. It's still a state-of-the-art approach to software development, with some modifications here and there, but for the most part, it's intact.
Quality learning in software development
Yuriy: I totally agree with you on the need to study. We see a similar situation in design where lots of designers are switchers from other industries because there was no UX education 10 years ago. In most cases, it was like boot camps and courses. So, you had to switch from other industries. But then they started working on projects, and it was OK because the level of user experience was so poor that even if you just had a designer, it was already much better. But that doesn't mean that it’s good enough. It's similar to the state of Agile. People think that they are Agile, that they're doing a good job. But it’s a question—if you compare yourself to what could actually be done, what kind of process you could have. And I agree with you, we are at an early stage because we can do much more.
Joshua: Yes, yes. I worry too when we talk about scholars. The thing is, scholars study scholarly works. Scholars study the best literature from the best instructors. We have a forest of courses and books and things out there. How do you choose the best of the best stuff? That's important because what we're seeing is people—even people who want to learn TDD—you know, they're going to some of these websites that charge $15 for a TDD course, and they're not learning TDD. They're learning from a deeply inexperienced instructor who threw together a video-based course. And it's scary. We've been analyzing them lately and just going like, "Oh my gosh," you know, it's already hard to teach people TDD—test-driven development. Now it's even harder because they're learning the wrong way, and they think they know it. So, a lot of challenges in the software industry.
Yuriy: The problem is that the industry has always been growing so fast. I’ve heard that research shows the average product manager has four years of experience as a product manager. Pretty similar team compositions in many teams. Like you have lots of people who have a few years of experience, and then you want them to know everything. We expect them to know business; we expect them to know all the frameworks, all the new libraries, and it's hard.
Joshua: Yeah, I once asked Jerry Weinberg—the famous Jerry Weinberg, who's written 30 books and is an industry legend—"How do you keep up with all the stuff that's out there?" And he said, "Easy. I only read the best stuff. I only study the best stuff." So, there are hundreds, thousands of books, right? I mean, you’ve got to just pick the ones that are the best. So, to me, as a product manager or whatever role you want to play in the software field, discover what those great works are or who those great instructors are, and just study with them. And it’s a lot easier, right? You won't have to worry so much about keeping up with everything
Overcoming team resistance to change
Yuriy: During your career, did you have a situation where you came to a team and you see, okay, we can't help them? So it's an impossible scenario. It's easier to build a new team than change this one. Or when you come to the company and see, okay, that's a good place to change things—we can do this, we can help.
Joshua: Yeah, we started doing assessments very early on. And the assessments give us a chance to talk to the people who would be going through the potential change. And if they, for the most part, don't want anything to do with it—they don't want a change—we say, "This is a waste of time." There’s no point in working with these folks. Or it could be, you know, it's actually just a bad time to start this work, this change. It's not good. You're right in the middle of something, and it would be disruptive to start it now, so let's wait. But for the most part, if people don't want to change, you've got to walk away. It's a waste of time and money.
Why software success is fragile
Yuriy: Did you measure the success of your projects when you finished consultancy, when you finished the training? Do you know what the success was and how many teams actually improved? Or is it really hard to measure because it's invisible?
Joshua: We look at DORA metrics, we look at whether they are continuously improving after we leave. We look at whether their customers are happier, whether there are more frequent quality deployments, whether the software is atrophying or staying in good shape. Knowledge silos—often when we leave, a new manager comes along and says, “Why are people ensembling? Let's get them back to soloing.” They don't understand the value of ensembling, and therefore they think it's going to be more efficient to go back to soloing. So what is success? I mean, it can be a temporary success. And we've seen some of our greatest work just basically dismantled by venture capital companies that acquire the company and then take them back to the Stone Ages. So in some ways, it's castles made of sand. And you have to be humble enough to know that you're really ultimately helping to change people. And those people may go on to other projects and bring those skills with them. It’s hard to necessarily point to lasting successes, but I believe in the software field, things are constantly shifting and changing. What was a success one day might be viewed differently later on as they change it up without understanding it. Unfortunately, because software is so invisible, and because the process of building it is so invisible, it's very easy not to even be aware of value when it's there. I'm talking about things like how slow it is when we have knowledge silos—different people who are the only experts in one area of the software. If they leave or if something happens to them, we're stuck. That's one risk of many risks that we spend time mitigating through our process, through the way we work.
Know the financial climate before driving change
Yuriy: If there is a new manager in the company, a VP of design or head of design department, or a VP of product, and they want to change their organization, what kind of words would you recommend they use in the management meeting to influence changes, to start this transformation?
Joshua: You know, one thing I think is it really truly helps to understand the financial climate of the company before you start making a bunch of changes. I think that too often in business, people want to do something, but they're not aware of the financial context. So, if the company is really suffering financially, the appetite for change might be low. I mean, it has to be at least discussed, right? What kind of changes could we potentially consider doing? We have to—so I just think in business, understanding finances is really important. You can have self-organizing teams, but if they're unaware of the finances of the company or the department or the budget for that particular initiative, if they're unaware of that stuff, you're treating them like babies, and they're not babies. Making them aware of the finances and the financial constraints is very important to how they approach change. And that would be the same for any new manager: understand the company finances to be able to figure out what would really move the needle and help this organization.
Rapid round
Yuriy: Awesome. Maybe we can go to the rapid round—questions to answer, maybe a minute per question, so our audience can learn more about you. So, Joshua, how would you explain to your mother what you do?
Joshua: Mostly, we help people in the software industry become a lot more agile.
Yuriy: What book influenced your product or business vision before you started writing books, or maybe after? What is the most recommended book that influenced you?
Joshua: Well, that's a hard one for life. But in business, I would say a book called Selling the Invisible. Since I'm in the services industry, that book by Harry Beckwith was almost like a Bible. So I'd keep it by my desk all the time and pick up a short story from it and read it. That’s why I wrote Joy of Agility the same exact way—all short stories. It's meant to be, you pick it up, get some inspiration. So Selling the Invisible would be that book for business.
Yuriy: What is your favorite product that gave you the best experience?
Joshua: I've really, really enjoyed the collaborative nature of the Google suite of products—the slides, Google Slides, Google Docs—being able to work with others simultaneously on things like that. It's just been phenomenal. And of course, I've also loved IntelliJ and tools like that, which on the software side have automated things that were difficult in the past. Of course, I always want them to do more. The automated refactoring tools that were built into the IDEs were always just glorious to use. I mean, yeah, occasionally there'd be defects and things I didn't like, but that really changed the game for me for refactoring code. So I've always really enjoyed that.
Yuriy: Interesting. If you could have a dinner party with an influential person in product, software development, or design, who would it be?
Joshua: Well, I would definitely enjoy sitting down with Sir Jony Ive, who of course worked very closely with Steve Jobs. I think he was there all along the way helping to design those wonderful products. So, I think it'd be very, very interesting.
Yuriy: Okay, thanks, Joshua, for coming. That was insightful, that was interesting, and I guess partially practical. Hopefully, we will be able to advocate more for agility and the joy of agility in our teams, with projects, with our clients, with our companies. Maybe you have anything else you would like to add at the end?
Joshua: It's been a pleasure speaking with you, Yuriy. I really appreciate the time we spent together, and I hope it was valuable. So if you're interested in more things about Joy of Agility, there's a whole website called joyofagility.com, and pick up the book. I have the audio edition I narrated myself, so that's fun to listen to. And I hope it can help you become more agile.
