Embracing Agile Learning in Organizations

Is Agile still relevant in today’s fast-paced world? Brian and Joshua Kerievsky reveal the four game-changing principles of Modern Agile that prioritize safety, empowerment, and continuous value delivery.

Overview

In this episode, Brian Milner sits down with Joshua Kerievsky, a pioneer in the Agile community and the creator of Modern Agile.

They discuss how Agile practices have evolved, the critical role of safety and empowerment, and how to deliver value continuously in today’s fast-paced world. Don’t miss these insights into creating better teams, products, and results through simplicity and experimentation.

References and resources mentioned in the show:

Joshua Kerievsky
Industrial Logic
Joy of Agility by Joshua Kerievsky
Modern Agile
#33 Mob Programming with Woody Zuill
#51: The Secrets of Team Safety with Julie Chickering
Badass: Making Users Awesome by Kathy Sierra
The Power of Habit by Charles Duhigg
The Lean Startup by Eric Ries
Experimentation Matter: Unlocking the Potential of New Technologies for Innovation by Stefan H. Thomke
Agile For Leaders
Mike Cohn’s Better User Stories Course
Accurate Agile Planning Course
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Joshua Kerievsky is the founder and CEO of Industrial Logic and author of Joy of Agility. An early pioneer of Extreme Programming, Lean Software Development, and Lean Startup, Joshua is passionate about helping people achieve genuine agility through principle-based approaches like Modern Agile.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back. And this is another episode of the Agile Mentors podcast. I'm here as I always am. I am Brian Milner and today I am joined by Joshua Kerievsky and really excited to have Joshua here with us. Welcome in Joshua.

Joshua Kerievsky (00:16)
Thank you so much, Brian. Happy to be here.

Brian (00:19)
Very excited for Joshua to be here. Joshua's been around for a while. He's been doing this for a long time. He said, you know, when we were talking before, and he's been involved with Agile before, it was called Agile. And, you know, that probably tells you all you need to know there. But a couple other things here about him, just so that you kind of can place him a little bit. His company is Industrial Logic, Inc. and he's the CEO and founder of that company. He has a book called Joy of Agility that's out there that I highly recommend. It's a really great book. And he's also closely associated with something that maybe you've been aware of, maybe you've heard of, maybe you haven't, but something called Modern Agile. And that's what I thought we'd focus on here for our discussion is really to try to understand a little bit about it. especially for those of you, maybe you haven't heard of it, haven't been around it before. So... Why don't we start there, Joshua? Tell us a little bit about what was the need that was trying to be filled with something like modern Agile.

Joshua Kerievsky (01:19)
Well, it goes back to a conference I attended in Prague back in around 2015. And I was giving a speech, a keynote speech there, and that ended. And then I went and said, well, I'm going to go join the OpenSpace. And I was just looking at what people were talking about at the OpenSpace. And at that point in time, I had already been experimenting with a ton of stuff that just kind of different from what we had been doing 10 years earlier or even later than that. I mean, just this was new things that we were doing, whether it was continuous deployment or ideas from lean startup or ideas from the Poppendiecks and lean concepts applied to agility or just a lot of things that were just different. And none of the sessions I was seeing in the open space seemed to be talking about any of that stuff, like giving up story points or moving away from sprints until continuous flow. just nothing was being talked about. So I just said, well, I'm going to host a session, and I'll call it, I don't know, a modern Agile. And so that's as far as I got in terms of thinking about the name. I just wanted to run a session where we could talk about, there's a lot of new things we're doing that kind of display some of the older ideas. And they're very useful, I found. So the session ended up getting a lot of attention. 60, 70 people showed up there. So we had a big group. And it was well received. People were fascinated by the stuff that they weren't aware of. And so I then repeated this open space event in Berkeley. Like a month later, was Agile Open Door Cal in Berkeley was running and did it again. And again, there was tremendous interest. in this, so much so that I decided to write a blog and wrote the blog and started getting more conversations happening. And that sort of began the movement of describing this thing called Modern Agile. And it took a few twists and turns in the beginning, but it wasn't sort of, I guess, if anything, I felt like Agile needed to be a little more simple. in terms of what we were explaining, because it was starting to get very complex with frameworks, enterprise frameworks coming along like safe and just too many moving parts. And so what ended up happening is I wrote some things and people started to notice, there's kind of like four things there that are really valuable. One of them was The names changed a little bit over time. But anyway, what ended up was four principles emerged. And that really became modern Agile.

Brian (03:58)
That's awesome. just for listeners here, I've pitched attending conferences in the past. If you've listened to this podcast, you've heard me say that, and I'll create things come out of that. And here's an example, right? This is something that was open space discussion. Open space, if you're not familiar with that, at conferences, can, if there's an open space day or a couple of days, then anyone can present any topic they want. And whoever shows up is who shows up. And this one got a lot of attention. And a movement grew from this open space topic, which is awesome. So let's talk. You mentioned there's four principles here. And I like the distinction here we're making also between the frameworks and the practices versus the cultural aspects or the philosophy behind it. And returning to those roots a little bit more from what Agile originally was. So you mentioned there's kind of four areas of this. Let's walk our way through those. I know the first one, or one of the first ones here is make people awesome. So help us understand, what do you mean by make people awesome?

Joshua Kerievsky (04:59)
Probably the most controversial of principles, because you'll get people coming along saying, wait a minute, people are already awesome. What are you talking about? And it comes from my, I'm a big fan of Kathy Sierra. And her blog was incredible. And her book, she wrote a book called Badass, Making Users Awesome. And in her book, she was really wonderfully clear about

Brian (05:07)
You

Joshua Kerievsky (05:24)
that teams that build products ought to focus on the user of the products more than the product itself. In other words, she would say, don't try to create the world's best camera. Try to create the world's best photographers. Big subtle difference there. Like that is focusing so much on empowering the users, making them awesome at their work or whatever they're doing, whether it's art or accounting or whatever, whatever your product does, how can you give them something that elevates their skills, that gets them to a point of awesomeness faster? And that's what she was talking about. So I thought, what a wonderful message. And initially, I used language like make users awesome. you know, having been an entrepreneur myself and created products and sold them and You learn a heck of a lot when you make your own product. And we've made several products over the years at Industrial Logic, probably the most successful of which was our e-learning software. And that has taught me so many, so many lessons. One of them is you have to serve an ecosystem of people. You can't just make your main user awesome. What about the person who's buying the software? How do you make them awesome in terms of helping them buy something that's going to get used? If they buy your e-learning and they never use it, they've wasted a lot of money. So we've got to make sure that their reputation is intact because they made an excellent investment and it got used and it got into valuable, it created value in the company. So how do I make the buyer awesome? How do I make the person that like rolls out the licenses to people awesome? How do I make their experience awesome? How do I make my colleagues awesome so that we love what we're doing and really enjoy working together? So it kind of morphed from make users awesome to make people awesome. And it's so expanded. If anything, we set the bar higher. And all of the principles of modern agile are like unachievable. They're all kind of high bars, right? But they're the goal that we go towards. So that really is it. It's about creating

Brian (07:23)
Ha

Joshua Kerievsky (07:35)
you know, wonderful, you know, the in Great Britain, they use awesome kind of sarcastically sometimes, right? They'll say, well, that's awesome. You know, and so for them, it would be brilliant. You know, I thought of making an English version. We have many translations of modern agile, and I thought of making an English version, which would be a proper British English version, make people brilliant. But it's meant to be to empower folks to give them something. And it's so it is.

Brian (07:43)
Ha You

Joshua Kerievsky (08:04)
It does have a product focus in the sense of we're typically building a system or a product that someone's going to use and it's going to give them skills they didn't have before or abilities they didn't have before that are going to be very valuable.

Brian (08:18)
Yeah, I love that. And there's a sort of a servant nature to that servant leaders, not servant leadership as much, but servant nature of I'm serving these people and how do I, how do I serve them in a way that really empowers them? Kind of reminds me of like, you know, the, the great principle with, with dev ops of just, know, if I can, if I can empower the developers to be able to do these things on their own. And so they don't need someone else to come and check the box and do everything for them. You're making them awesome. You're empowering them to be more than they were otherwise.

Joshua Kerievsky (08:54)
Yes, yes, absolutely. I I think we've seen a history in the software field of a lot of tools coming along and helping. It's not just tools, it's also methods as well. I mean, I'm entirely grateful to the Agile software development movement because it helped nudge everything towards a far better way of working and to make us more awesome at our craft. yeah, you have to have a North Star though. If you're going to build something, You have to know, what are we going for here? What are we shooting for? And with Cathy's influence, again, it's not so much make the greatest product in the world. It's, that focus on the users, the people who are going to be using the work, using the product.

Brian (09:34)
That's really good. Let's talk about the second one then on my list here, the make safety a prerequisite. What was the point here behind this principle?

Joshua Kerievsky (09:40)
Yes. So starting probably around 2011 or so, I could not stand going to the Agile Conference anymore. It had just become too commercial and too filled with just people hocking stuff. And it just was bothering me too much. I couldn't go. So I ended up going to South by Southwest, which is an

Brian (09:54)
You

Joshua Kerievsky (10:09)
Enormous conference tens of thousands of people show up So it'd be 20,000 30,000 40,000 people showing up for these for this event, which is musical film technology just it's just wild and I came across this book by Charles Duhigg called the power of habit. He was there that year and In that book. Well, first of all that particular year was 2012 that I went my first year there it poured The rain, it was every day, it was unusual for that time, but it was just like pouring rain. So what could you do? I bought some books and I was sitting there in my room reading them. And I'm reading this book, The Power of Habit, and I come across this chapter called The Ballad of Paul O'Neill. Now who the heck's Paul O'Neill? Well, it turns out Paul O'Neill is this incredible guy, a complete business maverick. He ended up becoming the treasury secretary under Bush and not. in 2000 for a short period of time, but that's another story. And he ran Alcoa for about 13 or 14 years. And so the Ballot of Paul O'Neill is very much about what he did at Alcoa to turn the company around. And in essence, you could say he made safety a prerequisite. That safety was his guiding light in turning that company around, which meant left people empowered to do all kinds of things. So it went way beyond safety, but started there. And it's an incredible story. I've written about it in Joy of Agility. I got so into Paul O'Neill that I ended up interviewing his main lieutenant. And then I got a chance to interview him a couple of times. the man's a genius. He passed away a few years back. Absolute genius. this concept of safety started to really pull at me in the sense that I felt, first of all, extreme programming, and I'm a big practitioner of extreme programming, brings a tremendous amount of safety to software development. It may not be as explicit in saying safety, safety, safety. When you look at extreme programming, doesn't really talk about safety, but it's implicit. And these days, Kent Beck's much more vocal about, you One of his missions is to make software development safer for geeks. But safety to me is almost like I found my home. Like safety was something that, what I learned through Paul O'Neill was that it's a doorway to excellence. And he transformed a hundred year old company with safety. I would complain about companies we were working with that were 25 years old and had an embedded culture. Like, how are we gonna change this company? But safety started to be this thing that I hadn't really thought enough about, and making it explicit opened up a lot of doors, right? And I became very interested in the work of Amy Edmondson, who's extremely famous today, but back then she was not so famous. And huge fan of hers. I, you know, I can email her and she'll email me back and she wrote a nice thing about my book. So. She has done some incredible work there. And so when we talk about safety in modern agile, it's psychological safety. It's financial safety. It's any of the safeties. There are many safeties that we could talk about. And it looks at all of them, right? It's brand safety, software safety in terms of security. you know, of the software and on and on and on. So make safety prerequisite is vast and big in terms of what we're trying to do there. Making it a prerequisite means it's not an afterthought and it's not a priority that shifts with the winds. It is permanent. It is something that we know we have to have in place. And it's very, very hard to achieve. Just like make people awesome is hard to achieve. Boy, is make safety a prerequisite difficult.

Brian (13:43)
Hmm. Yeah, I love Amy Edmondson's work as well. I'm just kind of curious. does the safety kind of inclusive of things like quality as well? Do you intend that to be part of what you mean by safety?

Joshua Kerievsky (14:11)
Well, mean, to the extent that it makes it safer to do good software development. So if bugs are happening all the time, you can't make people awesome, typically if you don't have quality. If you have really poor quality, nobody's being made awesome. They're experiencing all kinds of problems with your product. So make people awesome and make safety a prerequisite are very much tied together. That is, there is no real excellence without safety. You could think you're having an excellent experience, so that all of a sudden there's a major problem, and boy, are you unhappy. So they really go hand in hand. You could have the most incredible restaurant, and then one day you've got food poisoning happening. Great, no one's come to your restaurant. So you will not make anyone awesome if you don't make safety a prerequisite, and quality is part of that.

Brian (14:57)
Awesome. Well, let's move on to the next one then, because the next category is one that just resonates with me a lot. Experiment and learn rapidly. What was kind of the thought behind this one?

Joshua Kerievsky (15:06)
Yeah, and this is one where it that's shorthand, if you will, because you can only fit so many words on a wheel there. But it's important to know that that really means experiment rapidly and learn rapidly. And that comes a lot out of it in the influences of something like Lean Startup. I'm a huge fan of that book and of Eric's work, Eric Reese's work.

Brian (15:13)
Ha

Joshua Kerievsky (15:29)
And the fact that we can experiment rapidly and learn rapidly rather than just building everything and then learning slowly. Right? How can we do cheap experiments quickly to decide what's important to work on and what isn't? Let's not build stuff nobody wants. Let's find more time with our customers and understand their needs better so we can build the right things that make them awesome. In other words, and a lot of these are interconnected. In many respects, modern Agile is a Venn diagram. ideally want all four principles to be overlapping. And right there in that middle is where you really want to be. Not easy. But experimenting, learning rapidly, yeah. So challenge yourself to find ways to do quick, cheap, useful experiments. You can do lot of unuseful experiments. Amazon experienced that. There's a story in my book about how Amazon had to start just shepherding the experiments a little more and having some better criteria. Because you could do an endless array of experiments and not get anywhere. There's a wonderful book called Experimentation Matters by a Harvard business professor. Wonderful book as well. But I love experimentation and learning. And I see it as critical to building great products. So that's that principle there.

Brian (16:46)
Yeah, there's a real difference, I think, in organizations that put value on that learning process. if you see it as a valuable thing, that we invest time to gain knowledge, then that really can truly make an impact when you go forward. I know I've talked about this in classes sometimes where people will say, isn't it a little bit selfish from the organization to try to always just figure out what's going to sell the best? or what's going to work the best in advance of putting something out. My response is always, well, yes, there is a benefit to the business, but there's a benefit to the customer as well because they would rather you work on things that they care more about.

Joshua Kerievsky (17:24)
That's right. Yeah. I mean, we once put out an experimental product to a large automotive company. And we were really excited about it. We had a whole list of features we wanted to add to it. But we were like, you know what? Let's just get this primitive version kind of in their hands just to see what happens. it turned out that we learned very rapidly that they couldn't run the software at all. There was some proxy. that was preventing communication with our servers from their environment. So it was like, excellent. We learned really quickly that instead of those fancy new features we want to add to this thing, we're going to fix the proxy problem. And to me, that's the nature of evolutionary design is that we create something, get it out there quickly, and learn from it rapidly and evolve it. So it goes hand in hand with that as well.

Brian (18:11)
That's awesome. Well, there's one category left then, and that is deliver value continuously. So what was the genesis of that? Thinking about delivering value continuously.

Joshua Kerievsky (18:19)
So that was heavily influenced by my own journey into continuous delivery and continuous deployment and that whole world. We got into that very early. I was lucky enough to catch a video by Timothy Fritz, who he worked with Eric at IMBU. And he coined the term continuous deployment. And that video is actually no longer on the

Brian (18:43)
Ha

Joshua Kerievsky (18:44)
But this was something that I became enamored of was doing continuous deployment. And we started doing it at Industrial Logic with our own e-learning software back in about 2010. And by the time you get to like 2015, it's like, hey folks, there's this thing where you can do a little bit of work and ship it immediately to production in a very safe way, a safe deployment pipeline. It's friggin' awesome. But the principle doesn't just apply to that because this modern agile is not just about software development. It's how can I work in a way that gets value in front of people as fast as possible? So for example, if I'm working on a proposal, great, I'm not going to work for two weeks and then show you something. I'm going to put something together, a skeleton, I'm going to show it to you and say, what do you think? Does this add value? Where would we improve this? Blah, blah, Again, going hand in hand with evolutionary design. continuous delivery of value is something that is a way of working. With artists that I work with, they'll do a quick sketch or two or three sketches of something first before we start settling in on which one do we like the best and how do we want to craft and refine that. So there's a way of working in which you're delivering value much more finely grained and approaching continuously instead of in bigger batches.

Brian (20:05)
Yeah. I love the connection there between artists as well, because I've got a background in music, and I'm thinking about how when you go to write a song or create a new work like that, you start off with the roughest of demo tapes, and you move from there to increasingly more sophisticated versions of it until you finally have the finished product. But no one thinks that's strange or thinks that's weird in any way. But you're right. Sometimes there's this attitude or kind of I think in some organizations of, we can't let anyone see that until it's absolutely finished, until it's done.

Joshua Kerievsky (20:39)
Yeah, yeah, and that maybe that's that there's some fear there, you know, because they don't want to be thought of as, you know, being lesser because they put something rough in front of someone. Whereas I view it as a, you know, to me, it's a sign of weakness when you when you only send something polished because you haven't had the courage or the sense of safety to put something rough where we can make better decisions together early on. So. There's a lot of learning, I think, around that. But it's a challenging principle of its own, deliver value continuously. And people would say, well, what does value mean? Value is one of those words where it's unclear, because you could improve the internal design of a software system. Is that value? It probably is. But you've got to be able to quantify it or prove that it's going to help make things more graceful in terms of flowing features out. yeah, quantifying, communicating what the value is. is important. I'm also a big fan of maximizing the amount of work not done, as it says in the manifesto. So how can we do less and deliver more sooner? Our motto in industrial logic now is better software sooner. And a lot of these principles go straight into that. that drives it.

Brian (21:38)
Yeah. That's really great. Yeah, I love these four principles and I think that they really represent a lot. There's a lot that's baked into each one of these things. And I'm sure as you kind of put this together with the community and started to talk more about it, I'm sure there were some challenges. I'm sure people came up to you and said, well, what about and how about this? Is there anything now looking back on this that you'd say, gosh, we really... really didn't quite cover this or, know, this is maybe I could fudge it and squeeze it in this area, but you know, there's this other thing that I really think would be important to kind of mention here as well.

Joshua Kerievsky (22:28)
Well, you know, it's funny, because I thought I was going to write a book. I started collecting stories. I love telling stories, and I find stories to be a great way to help educate people. Not the only way, right? But as part of some of the workshops I give, you tell a story. Hopefully it's a story that's sticky, that sticks in the person's brain. And over the years, I collected stories like that, stories of agility. I thought I'd be writing a book about modern agile when I started writing Joy of Agility. Gradually, as I wrote more and more stories, they didn't quite fit into all those four principles. And I think the lesson I learned there was that I was starting to talk about what pure Agile means, the word Agile. What does it really mean to be Agile? Whereas modern Agile is really almost in the context of product development, of building services or products for people. Whereas Agile itself is even more pure. And so the... the book itself got into the difference between quickness and hurrying, which you can relate to this. You could say experiment and learn rapidly. Well, OK, maybe we shouldn't rush it. Don't rush. Be quick, but don't hurry is one of the mantras in Joy of Agility. So adapting, right? Adapting, we talk about adapting all the time. So to be agile, you need to be able to adapt quickly. These four principles in modern agile don't say anything about adapting.

Brian (23:46)
Ha

Joshua Kerievsky (23:48)
So that's kind of implied, but it's not there. So it's a different lens on agility. If anything, I'd say the make people awesome principles are not meant to. It created some dislike, I'd say, from some people. It could have been called empower people, potentially, although a lot of people really love make people awesome. I don't know so much what I'd change there. I'd say we have a .org. So it's a modernagile.org is a website. There's a pretty large Slack community, which, know, four or 5,000 people on that. We don't certify anyone in modern agile, so there's no certifications, but it's something that is neutral in the sense that whether you practice Scrum or Kanban or Safe or whatever, these principles can influence you. And, you know, but again, this all came out of like, when I went to that open space conference in Prague, I had no idea I was going to talk about modern agile. You know, it was not like a predetermined thing. It was just like, my God, they're not talking about the modern ways we're doing stuff. So, and I always encourage people to, you know, keep pushing the limits and keep modernizing. I said to my own company the other day, our wonderful ways of working that we've been doing now for years that have evolved, they're probably antiquated as of today. You know, with generative AI, what would we do differently? Let's have a perspective on our own work as it needs to be modernized constantly. So the term modern in modern agile means always be modernizing, always be looking. Okay, I've had people say, well, Josh, some things don't need to be modernized. There's things that are just evergreen. They're classic. I'm like, absolutely. I'm not changing evolutionary design anytime soon. I find it to be quite useful in so many contexts. So yes, there's the evergreen stuff. And then there's the stuff where you can, indeed, discover a better way. The manifesto itself says, we are discovering better ways of working. Great. Keep that going. Keep modernizing and looking for easier, simpler, quick, easy grace. as the dictionary definition of Agile says, how can we work with quick, easy grace? That's always going to be improving, hopefully.

Brian (26:12)
Love that, yeah. And you're right, I mean, think there's some, to some people I think that there's, I guess at times an attitude of, you this is all new stuff or this is a brand new concept and something they don't really see the connection backwards in time to how these things are all built on other ideas that have been progressive over the years. So the idea of, yeah, this is, you know, we're, we're not saying that certain ideas are bad because now we're trying to modernize them. We're just saying we're trying to apply that same principle forward into kind of the context of today, which I don't see anyone should have a problem with that.

Joshua Kerievsky (26:48)
That's right. That's right. Well, and if you are experimenting and learning rapidly with your own process, which I highly encourage, chances are the way you work today will be different than it was yesterday. You will be exploring, like we use discovery trees today. We didn't use them before. Years ago, no one knew what a story map was. There wasn't such a thing as a story map. Now we have story maps. There's constant improvement happening. And you've got to be open-minded and willing to try new things and drop old stuff. We thought sprints and iterations and extreme programming was absolutely fundamentally part of the way to work. Then we started experimenting with dropping them and turned out, wow, this is pretty cool. We like this. It works pretty darn well for our purposes. That came through experimentation. some of our experiments were terrible, just terrible. It's not an experiment if you already know the outcome. keep pushing the limits of what can make you happier and more joyful at work in terms of producing great stuff.

Brian (27:46)
Awesome. That's great stuff. Well, I can't thank you enough for coming on, Joshua. This is great stuff. just, you know, we'll put all the links to the books mentioned and everything else in our show notes for everybody. But as Joshua said, you can go to modernagile.org and find out more about this if you'd like to. You'll find information there about Joshua himself or his company again is Industrial Logic, Inc. And, you know, his book again, just to mention that, Joy of Agility. We were talking how some people get that title a little mixed up or whatever, but it's just the three words, joy of agility. So just look out for that book. I think you'll find it a rich resource for you. Joshua, thanks so much for coming on.

Joshua Kerievsky (28:25)
Thank you, Brian. Thanks to you. Thanks to Mountain Goat and the folks there. And I really appreciate chatting with you. It was really wonderful.