Episode 152: The Evolution of Agile: A Conversation with Joshua Kerievsky of Industrial Logic
In this episode of Product Thinking: Joshua Kerievsky, Founder and CEO of Industrial Logic, joins Melissa Perri to discuss the evolution of Agility in business. Josh talks through his fantastic new book ‘The Joy of Agility’ and the six mantras he’s identified in the implementation of Agile working into business strategy, and the case studies he discovered and learned from along the way.
You’ll hear them talk about:
08:30 - Agile is an adjective, not a noun. It’s not separate from product management, organization or Dev Ops. To be agile is to be quick, resourceful, and adaptive.
10:30 - The art of slowing down to speed up. Josh talks us through the first few of his Six Mantras from his book, mainly focusing on the importance of understanding when to be slow and when to be fast. The workload that goes into product development can be time-consuming, and skipping steps such as market research and analytics can lead to mediocre products being released and failing. From a software perspective, Josh talks about the art of chartering and the benefits to bringing multiple teams onto the same page: taking the opportunity to slow down and get your ducks in a row, before speeding up once more.
23:20 - Start Minimal and Evolve. Josh tells us how this applies to product management through the example of a Car Rental website, and how it works to involve all the key teams and build in risk management to the process. The conversation then turns to the case study of Chrysler’s Payment System, and the benefits they saw to starting their system small and evolving from there.
30:30 - What does Agility have to do with cross-functional collaboration? Josh tells us how businesses are often built around needless delays: not the good slow, but the bad slow! And suggests tactics on how to make this initiative a success. The conversation continues to discuss workload and delegation, and how he helps executives visualize problems their teams are facing. Do you say ‘no’ enough?
Episode Resources:
Other Resources:
Melissa - 00:00:36: Hello, and welcome to another episode of the Product Thinking podcast. Today we're talking about everybody's favorite subject, Agile. But I'm saying that sarcastically, so do not turn that dial yet, because I think you're gonna really enjoy this show. Okay. I'm joined by Joshua Kerievsky, who is the CEO of Industrial Logic and Joshua has been at the intersection of software development and Agile for 28 years. So he's seen it evolve in all shapes of forms. Josh always has had a really enlightened view on what Agile and agility means for organizations. And he recently wrote this book called Joy of Agility, where he explains that it's more of a whole company mindset and not about the dogmatic frameworks of Scrum and all those wonderful things like Safe. So we're going to talk to Joshua about the way that he views Agile. We're going to talk about a lot of the stories and examples that he puts in the book of whole company agility, which are fantastic. And it's going to give you a different perspective of what agility could really mean for your company. But before we dive in with Joshua, we're going to our Dear Melissa segment. On this segment, I'm answering your questions. Every single week. So go to dearmelissa.com and let me know what you have questions about. And it could be about anything. So let's hear from our caller this week. So I'm really excited that you get the chance to pitch your executives and help them understand what product-led means. Now, the thing to know and the thing to really hone in on here is that you have to put it into the language that the executives care about. So if you're trying to make a pitch for being product-led, why should they care? Right? You can't just be like, oh, we have a lot of product managers. This will be fantastic. It has to be something they care about. So they care about money. They care about how the business is going to grow. They care about beating competitors. They care about satisfying their customers. That's the type of language we need to talk in. So you might want to say some stuff like, in sales-led mode, we run the risk of building for one or a few customers because we are basically listening to their feature requests and putting them on the roadmap. And what happens there is that we could miss out on the opportunities to build to satisfy more customers or all of our customers because we're getting distracted by who's yelling the loudest. But in a product-led mode, we're not. In a product-led world, what we're doing instead is staying ahead of the strategy. We're constantly communicating with customers. We're pulling that back into our strategy for our product. We're getting ahead of what they want and what they need by doing a good practice like this and figuring out what's going to work in the long run. Sales will love it when we're product-led because we're going to be ahead of people asking for a lot of feature requests. And sure, it's not going to take all the feature requests away, but it should make a really big dent in it. And it will keep us innovative. If we're constantly talking to our customers, trying to figure out how we can scale and grow our product in a repeatable way, what that means is that we are going to be on the pulse of what's going to be innovative. It's going to keep us fresh as we develop our strategy. And we're going to make sure that it scales to the best markets, the best types of customers that we want to go after in a very strategic way. When we're product-led as well, what we're also doing internally is making sure that we're working on the most important things that we could be doing for the business. So we're going to see a lot of monetary outcomes that are good for that. We should see increased revenue. We should see decreased costs. And you, as a leader, will be able to trace all the things we're doing in product back into long-term and short-term company goals. That's the transparency that we want to provide. Also, product-led doesn't mean that product management is just rolling everything and that we don't care about sales or nobody else can participate in it. What it means is our product. Our product is fueling our growth. So we are carefully integrating our software and our business strategies to make sure that we can leverage software and all the great technology that's out there to solve our customers' problems in unique ways and ways that are going to allow us to win. But we still need to involve sales to hear what our customers are asking about and what are things happening in the market? How are they winning? What are they losing on sales? We also need to talk to support, developments included. Your thoughts are included in there. What we're doing as product managers and with a good product management team is taking all those things into account and helping to make decisions on a daily basis that will further our strategy. And those decisions will connect our business strategy back to our technical strategy to make sure that we're winning there. That's what we're really trying to do in a product-led world. Really focus on our customers' problems, solve the right problems at the right time, and make sure that they are beneficial for both the business and the customer. And that should allow us to go faster because we are being strategic. So we are making sure that we're doing the top priorities. We are evaluating opportunity costs. We are aligned towards our business goals, and we're all moving in the same direction. That's what we can get from being product-led. So hopefully that helps you give a little bit of a pitch. And feel free to tweak that in any other ways or any examples that you've seen work there to really communicate the money and the business side of these things. But one of the other things they're going to ask about is, how does this change? So you should be ready with some kind of view of how we all work together when we're product-led. That's one of the biggest issues that I see with executives and especially people in other departments. They're like, OK, if you're becoming product-led, how do we work with you? So maybe map out as well how sales pulls into it. How techs. How you're involved in it. Where the executives pull in. Where everybody else in the organization can come and give feedback or tell you what's happening with the customers or how their inputs get translated into a product strategy. And it's not about just, hey, you can submit a bunch of feature request ideas here and they go into a backlog. It's more like, I'm going to go talk to sales about what our win-loss looks like right now. And this happens on a monthly basis. You can tell me where we're winning, where we're losing. We're going to be pulling the data in there, and we're going to be looking at that. And having conversations with you about what you perceive as things that we could be concentrating on to win. That's what we're talking about of how everything kind of pulls in. So most executives, when they haven't worked in this way before, they don't know what that looks like. And that makes them nervous. So concentrate on what the value is. And then do a little overview of how it works and how everybody else plugs in. And I think that's the thing that's going to win you over. All right. I hope that helps. And again, if you have any questions for me, please go to dearmelissa.com and let me know what they are. Now let's go talk to Joshua.
Ad - 00:07:13: Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund's Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at hustlefund.vc/mp. find the link in our show notes.
Melissa - 00:07:50: Welcome, Joshua. It's good to have you on the show.
Joshua - 00:07:52: Thanks, Melissa. It's a pleasure to be here.
Melissa - 00:07:54: So I really want to get your perspective on this because you have been working in software development in the intersection of Agile for over 20 years now, right? For a long time. Tell me a little bit about how Agile has evolved in your opinion since you got started with Industrial Logic, which is your company. Since you started this, since you started looking into XP, what have you seen as like the shift of Agile and where are we today?
Joshua - 00:08:21: My perspective has maybe gotten broader and broader over time in many ways. And in many ways, you could say it's extremely narrow because it's a definition. I've come to see Agile as an adjective. So in some sense, I started with looking at agility and software development. And today I view it as a humble adjective that can apply to many things in work and life. And why did I make that shift? I mean, it's just that I've found that Agile should not be put in a box. Agile is not separate from product management or separate from org design or separate from DevOps. To be Agile means to be quick, resourceful, and adaptive. And frankly, I need to be that way on the tennis court. I play a lot of tennis. I need to be that way in business, in all aspects of business, and certainly in aspects of life. It helps to be Agile, especially in a world that's changing all the time. So yes, my understanding and conception of agility has gone into this mode of, this is an adjective of some very important words, quickness, resourcefulness, adaptiveness.
Melissa - 00:09:24: Work with a lot of like really large companies too on this. Do you see them understand that? Or are people misinterpreting Agile these days?
Joshua - 00:09:31: I think that some people think I'm Don Quixote and I'm going after this crazy idea that we could actually change the conception of Agile to be back to the definition and that it's a wild quest, which is impossible to, it's impossible to change the meaning of the word at this point. So no, I don't think anyone really listens to me as far as the large corporations go. I think more and more corporations are understanding that it's agility. So they're saying agility more often. I'm seeing a trend more and more people saying agility instead of Agile. Now, is that really going to affect a major change? I don't know. But agility, at least maybe it says like, let's be Agile, not let's follow a methodology. Let's follow a framework. Let's follow some kind of predefined approach.
Melissa - 00:10:16: I think that's good. I do hear agility being thrown around a lot more too. And I think that's probably for the best, but I'm skeptical on whether or not it's going to be put into place. This broader term, I like it. I like how you're talking about it. And you did go deeper into trying to explain agility in your mindset and how that you define it in your new book. So it's called Joy of Agility. I really loved it. You've got tons of short stories of all different cases of agility, which is really cool. So there's like stories about Oprah Winfrey in there, American Airlines, all these different companies, which are really, really cool. And I thought that was nice. Super short, little stories, love the format. But what was really neat about it too, is that you've got these six mantras about agility and how we should be thinking about it. Can you walk us through those mantras and tell us how they relate back to being Agile?
Joshua - 00:11:07: Absolutely. The mantras came out of writing the book. They literally, I did not pre-plan the mantras. They were not in a table of contents. What I wanted to do is share my favorite stories of agility. And so over the years, I kept writing these stories. And at some point, I had a large pile of stories with no organization whatsoever. No publisher would ever go after such a book, right? You got to have an organization. So I was like, all right, great. How do I fit these into things? And at some point, I thought about Modern Agile. There's four principles in Modern Agile, but they didn't quite fit there. And the deeper I got into my research for the stories and writing the stories, the more I fell in love with some of the ideas I was learning about. Some of them were phrases that gurus have said in the past. W. Edwards Deming said, you know, the manager's job is to drive out fear. And so drive out fear is one of the six mantras. It's a mantra that's very closely aligned with the Modern Agile principle, make safety a prerequisite. So driving out fear, huge. Like I have a client, right now, they're in legal tech, and it's a really cool product that we're helping them build. And I've said to them, you know, one of the issues you have to deal with is, are people afraid to use this? Are they potentially afraid that this is illegal because it's a totally different way of doing something? Or could they fear maybe the data being ripped off if it's in the cloud, right? So fear dominates a lot of our thoughts. And so drive out fear is just an incredibly important mantra. Now you could say, well, what does that have to do with agility? If you're afraid, you typically are slow. You do not move with quick, easy grace. So fear slows you down. There's lots of stories in the book about this, one of which is about the building of the Golden Gate Bridge. And when they built it, first of all, there were decades that passed where they said, it cannot be done. No one could put a bridge there. It's too long. The span is too wide. There's no way. And eventually an architect came along and said, no, no, no, we can do this. It's a remarkable story. But one of the most interesting parts of the story is that they approached it from the perspective of, we are going to make this the safest, construction project of all time. They built a makeshift hospital near the bridge. They had people wear like safety goggles, which was never something they'd done before. They adapted mining helmets. People didn't wear helmets back then when they did construction. So they took mining helmets and adapted them to work on the bridge. They said, if you're caught, not strapped in with your harness on the bridge, you'll be fired on the spot. One particular veteran craftsperson was fired on the spot for not harnessing it. But what was most remarkable was this was the depression. And in the early 1930s, they were able to get $130,000, which was a lot of money back then, to build a net underneath the bridge while they built the roadway. So if the wind was blowing and it howls in the Bay Area, people could get blown off the bridge and fall into the ocean and die. This net caught about 19 people. They ended up becoming a club called the Halfway to Hell Club but what happened was that the safety, especially that net, helped improve performance, helped increase productivity, right? They were running a little behind schedule with all that safety. It really helped them move faster. So I believe that safety is integral to speed.
Melissa - 00:14:16: And I feel like a lot of people would think the opposite of it in companies, that the more things that you put in the way or surrounding your projects that might help safety will actually slow you down. But you've seen the opposite.
Joshua - 00:14:28: That's really well said because there's so many companies that they try to put all these little gates in your way to protect. You've got to do these code reviews and they have to happen by someone else. And then they have to happen at a certain point in time. Whereas a lot of times what we'll do is, well, how could we make that happen in real time? How could we get rid of the delay of waiting on a code review by doing it together while we're coding? So we look for all these ways to build in real safety. People try to create safety, but sometimes create a lot of delay. And there's cost to that, obviously. So you're wanting me to go through the mantra. So drive out fear is one of them. So be quick, but don't hurry is another. If any of them jump out that you want me to go dive deeper into, I'm happy to. But that one's really important. Most of us have stories of where we hurried and something went really poorly because of it. Big mistake. One guy in a workshop told me, I was asking all the students, what's your story of where you hurried one day and it was a big problem for me. This one guy, he accidentally, he was hurrying, taking his motorcycle out of his garage. He didn't put the kickstand down properly because he was hurrying. It fell on his leg. Broke his leg. And then for the next 10 years, he dealt with issues around that leg before it got really fully, fully healed.
Melissa - 00:15:36: When you're thinking about like be quick, but don't hurry in organizations, especially when they think about Agile, I found that many organizations adopted agile because of speed on that side. They said, we want to be fast. We want to be fast. But then you find that they're not going fast enough. They're trying to rush everybody, give them more and more stuff to work on. How can you tell if an organization is, let's say, hurrying? Like what's the difference or what's the signs of, hey, we're actually not in a good speed, right? We're rushing things or we're hurrying them. What are signals?
Joshua - 00:16:05: Typical signal is everyone is so busy, out of their minds busy, way too much stuff to do. There's too much work in progress. They have not done a decent job of prioritizing what's important. Maybe they haven't looked at the cost of delay and really chosen what is the highest value work for us to be doing. And what's not? What could be paused? What could we say no to? People are just running after a million different objectives. And the busyness is the biggest signal that they're rushing and hurrying.
Melissa - 00:16:32: It sounds to me speed, when we think about it with agility, is more about getting the right things done faster and at a good pace. But we get into this trap of hurrying. It's like we're taking on too much and we're just trying to rush through all of it.
Joshua - 00:16:45: That's right. And here's an interesting thing. There's a relationship between slowness and speed. That is, it's important to know when to be slow and when to be fast. And if you don't know how to do that dance, you're typically not going to be fast. So I'll just give you an example. Unfortunately, I do a lot of tennis examples, but if the ball is coming towards you and you have not prepared, just think about it. Last minute, you're going to try to put the racket back and hit it. If you watch the pros, they very slowly bring their racket back to prepare. It's a slow movement. It's not a fast movement, but then they're prepared and then boom, they can hit it really fast and hard with their stroke. That's the stance between slow and fast. So preparation tends to be slow. You're preparing, you're doing your homework on customers, you're doing your homework on competitors. You're able to be slow and analytical in order to be fast in the marketplace, right? So this understanding the relationship between slowness and speed, I think is very important for being fast without hurrying.
Melissa - 00:17:38: I see that a lot in product management. And that comes back to like formulating our product strategy. A lot of people try to rush through that. They take on too much and then they end up busy like you were talking about. And when we do some of these like product strategy projects that I've been a part of where we have to reset an organization, for example, I'll do that a lot when I'm on a board or coming in and helping people who are trying to turn their org around. There's actually a lot of work and a lot of thinking that needs to go into crafting that product strategy well. And like you said, go figure out your customers, look at your competitors, but diving into the data, pulling out the data, setting it up well so that we can actually monitor it when we go through it, doing a bunch of user research, coming back and going through that user research, maybe doing it again if we have to hone in on things. And you see people get frustrated with this amount of work because they don't see results coming through. But then if they try to rush through that and not do it correctly, they've got people just shipping a bunch of stuff that's going in no direction. And I always see that kind of frustration. Where people don't realize it's okay to go slow for a while. And maybe we do some of this strategy work for a couple months and then we're set and then people could start to run. On the software side, what have you seen as things that you need to prepare for, what people should be thinking about as they approach this to get ready to speed up?
Joshua - 00:18:56: I'll just echo what you're saying because I love it. And it's exactly right. Because just to say the work you're doing in that strategy work, that could feel slow. But imagine. You're putting out a mediocre product fast. You put out a mediocre product in a hurry. You haven't done your competitive analysis. You don't have any ways of looking at metrics, nothing. And it doesn't go anywhere. So great. You hurried. You got something out the door, but it's not a fit. So slowing down is so important. We do chartering. We've been doing it for years. I learned it from a guy named Three. And chartering is a great way to get really clear on what the heck are we going after here in the market. It's not as deep as what you're talking about at all, but it at least gets the whole group aligned on what are we going after? What are we going after? Who needs to be part of this? How would we know if we're successful? How are we going to work together? It's a kind of a slowing down at the beginning to get clear alignment and inspiration on what we're going after.
Melissa - 00:19:47: When you're thinking about chartering, tell me more about that because I know a little bit about it because I know you, but what's the like scope of it? Do you do it for teams? Do you do it for large parts of the organization? And like what makes up a good charter?
Joshua - 00:19:58: Charters can be done at any level, really. Most of the time we're doing it for the products that we're building. We just recently helped a company build a point of sale system. And so we did chartering with them. And the executives were part of it. The product management was part of it. UX was part of it. Operations, everybody. We got some very large community of people involved in this. And we get super clear on why are we doing this project? What is this point of sale? What's it meant to do out there? How is it going to compete? How would we know if it's successful? Who are the key players in this community? So we know them and we can interact with them if we need to. How are we going to work together? For us, many times it's often at the product or initiative level. We're going after something. We're building something. How can we be aligned and understand that? But it's not as deep as what you're talking about, where it's not getting into competitive analysis and data and all that stuff, which also obviously is hugely valuable. And it's part of slowing down. Part of slowing down in order to go fast and be effective.
Melissa - 00:20:53: To me, it sounds like chartering too is kind of what you do once you've got this picture of where you want to go. And it's about how you align those teams. And I would almost call it like it relates back to me as the collection of the vision and the strategy and the outcomes and the stuff. It's like pulling it all together and aligning people on what that is.
Joshua - 00:21:10: That's exactly right. Yes. So you're right. It's probably coming after you've done enough of the pre-work to know that this is something worth going after and let's pull together people to actually do it.
Melissa - 00:21:20: So chartering helps us slow down to speed up. What's another one of your principles that you really like, the mantras?
Joshua - 00:21:27: Clearly like writing tests. So we write lots of automated tests, right? And when I first encountered this in the 90s, I had not been writing automated tests. I did a lot of manual testing. I was very good at just manually testing software, but slowing down to write an automated test and that's like, that's going to make me go faster. Turns out, yeah, it really will. I mean, on the point of sale system, we've built over 6,000 tests, automated tests, that all these little micro tests that run really fast, all of them run in a minute, one minute. And there's 6,000 little tests of logic. That's a huge safety net. Talk about drive out fear, but when it comes to making a change to that complex software, that safety net catches you quickly if you make a mistake. It's not intuitive. A lot of people don't do what we do. They don't take time to write automated tests or to do test-driven development, but that slowing down and creating that environment produces awesome speed.
Melissa - 00:22:19: I think a lot of organizations are probably out there trying to figure out leaders maybe who aren't super aware of all these different methods. What do I invest in, right? What should I say? Yeah, let's take some time and do this thing. It might slow us down, but it's going to be worth it at the end of the day. What's your advice for people who are trying to like evaluate that? Like, how do you think through should we do like I know I think we all know we should do automated tests. Let's call it a new concept. How do we think through whether that's going to be the right concept or it's not going to help us in the long run or this is something worth investing in?
Joshua - 00:22:51: I mean, a lot of companies just have way too many defects. They're spending so much time on fixing things that are broken. And so clearly, that's a very poor use of their time. They'd much rather be spending time innovating, spending time working on doing more research for what they should actually build, and not just fixing broken stuff. So if they're fixing broken stuff all the time, clearly this is a candidate for them to have a much higher quality code base, higher quality product, better metrics to understand what parts of the system really are in high use, but have very poor quality. So we know what to fix. That's definitely a strong area for this.
Melissa - 00:23:26: One of your other mantras as well speaks to me in the product management area. It's start minimal and evolve. Can you talk a little bit about that mantra and why it relates back to agility?
Joshua - 00:23:36: First of all, we don't know what we don't know yet. So let's do sketching like an artist would do. Let's just sketch something and put some things in front of people and say, is this kind of what you want? I'm not going to invest a ton of time in it beforehand before I learn. So start minimal and evolve applies to many, many things, right? Like you could have just a very minimalistic design for your system. Let's say I'm building a rental car system. I could say, well, we're going to stand up a system that allows someone to rent a car. But it's going to be very, very basic. It's going to say you can only rent a car from this one location and return it to that one location. We only support one vehicle type and that's it. But we'll have the user interface. We'll have the database. We'll have the middleware. Everything will kind of be set up. It's just very, very embryonic. And then we go from there. Now, think about that, because if that involves like three or four different teams, maybe in two continents, suddenly we're getting everyone aligned. We're getting everybody working together. We stood up some software. We showed to people it works. It's just. It's just primitive. We're not shipping it yet. There's a lot of risk management baked into that. And that is starting minimal and evolving versus this team's building the front end. And this team's building the back end. And everybody's building their own thing. And then eventually they're supposed to like integrate and it takes forever. It's headaches and stuff. That's the concept in a software context. We found it to be an incredible tool for managing risk.
Melissa - 00:24:58: So this kind of comes back into like minimum viable products and everybody misunderstands that term, but it's that concept of how do we produce something that meets the requirements and is desirable and it's lovable and it's going to help solve problems in a small way, make sure it works and then invest in the full thing.
Joshua - 00:25:16: That's right. Should we even build it? What's the sketch of a fake feature? I talk about that in the book of feature fakes that I learned from Laura Klein. And Laura has this wonderful technique and it's like, you don't want to overuse it, but you could sometimes occasionally, you know, use this tool where you put a fake feature in your system and get data from it before you ever invested in building it. And my God, that's like an incredible way to save time, learn quickly. Well, maybe it's related to your build trap, right? Don't build it, first learn. Learn if anyone even wants this darn thing. Yeah.
Melissa - 00:25:47: Yeah, that resonates too. I think what happened with people with MVPs, it makes so much sense to me, right? And it's exactly what you said. If you operate in this way, it reduces risk. And so many companies are afraid of risk. They got chief risk officer. They're all worried about compliance, all this stuff. But then they don't think about what if we just invested a couple million dollars building the wrong thing, rather than taking some time to make sure it's the right thing before we go heads down and go on this path. And to me, that's so risky. That's so risky to not do things in minimal ways. But I think MVP and the word minimal kind of like set people off down this weird path where they were doing it wrong. And what I like about in the book is you give, for example, the guitar where you say, hey, the first guitar was like one string and you could pretty much play on it. But it had just the basic necessities on there to play a song, to get the outcome that you're looking at. And then from there, it evolved. What's a great story that you have in the book that you love? About somebody who, one of the companies or somebody who took something small and then evolved it from here.
Joshua - 00:26:49: For some reason, I'm thinking of a story that's not in the book, but it's a pivotal story from the birthplace of extreme programming, which was the Chrysler compensation system. It was a payroll system. So basically, you know, paying people's paychecks and very, very, very complicated. The team that came before the XP team arrived, Kent Beck and Ron Jeffries and a bunch of others, they were in analysis paralysis because there were so many complicated scenarios to deal with that they just weren't able to build the software. Kent came in and his friends and started saying, well, let's just stand up the most basic little payroll system to begin with. It's very, very basic, doesn't handle taxes. It doesn't handle vacation time. It doesn't handle any of this stuff. And they got that up and running very, very rapidly. And then they evolved it. What's the next thing and the next thing and the next thing? That approach just worked extremely well. Eventually, they have the entire thing humming along. We've done this for so many clients. We had a client that the Nielsen Media. People. And they had a data warehouse group. They had mainframe group. They had Java programmers. They had product managers. We got them all in the same room. And we started building this really important new system for them, which was related to like DVRs. You know how people were no longer watching live TV and just record. They needed a new system to handle that. We built it with this large team, 32 people in one room, one large room in Florida. It was had caves in commons. And we stood up a very embryonic version. Of this report that needed to be generated. Very basic to begin with. Just the most basic scenario. And then we get to the next one and the next one and the next one evolving, evolving, evolving until we were ahead of schedule. We were pulling stuff from release two into release one because it was moving along so nicely. So I would say evolutionary design, as I like to call it, which is start minimal and evolve is probably one of the most pragmatic and practical and important Agile practices.
Melissa - 00:28:44: When you are trying to help people learn how to start minimally, but let's say not go to minimum, right, which is what happened with MVPs. I think people got... They weren't thinking about what they wanted to test, right? And they would just throw stuff up there. And it wasn't good for a long time, especially like during lean startup days back around like 2010, 2011. What's your best approach for helping people try to figure out what to slim down?
Joshua - 00:29:08: I like to say, just say no to Nancy Reagan. Just say no. It's no, no, no. I'm not doing that. I'm not building that. I'm not building that. I'll give you a quick example. We have a little mobile game that we play with people, and it involves dice. Now, the in-person version is real dice, but the mobile version, the image of a dice on your phone. And you have to flip the dice into different configurations and stuff. When we first started working on this, I was like, I don't even know if we want to build this because I frankly don't know what it's going to feel like to do that. And so one of our programmers came along and he was new to Industrial Logic. So he thought, well, it's Industrial Logic. I better do test driven development for this dice flipping. And I was like, you don't need to waste your time. We're just sketching right now. Let's just write some quick code to see what it would feel like to move a die on a mobile phone. Don't spend a lot of time on this because we want to invalidate the idea or validate the idea as quickly as humanly possible. This is not production code yet. So I don't know if I'm telling the right story for you, but just internally, we try to block the talk. And there was no point in writing finely crafted software at that point in time because, hey, we're just trying to see if this is worthwhile. It turned out it was. And then we did throw out that code and we did test drive it. And so now it's production code. You got to learn what to not do. What I tell folks is say no to most features. Find the essence. If it's a car rental system, I got to be able to rent the car. And return it. So what could I say no to? What are all the bells and whistles that I don't need right now?
Melissa - 00:30:34: Good life lesson there. One of the other things that came out to me in a lot of the stories that you're looking at too is the fact that in a lot of these cases, like you were talking about with some of the companies you just worked with and the teams, you're bringing people together from all across the organization. And it's not just product and engineering or, design, product and engineering, going into a room and like figuring it out. What does agility have to do with cross-functional collaboration and bringing the right people into the room?
Joshua - 00:31:03: Well, we are always looking for delays. We're always looking for what's really slowing us down needlessly. This is not the good slow. Good slow is where you're learning, preparing, analyzing. But the bad slow, we're just delayed. We're delayed for no good reason. It's because we're broke or configured in different teams that don't collaborate. Each team has its own backlog. And you're really important items at the bottom of another team's backlog. Great. What's that doing for the speed and adaptability of the organization? So we work very hard with most companies to create cross-functional teams. And that means we will beg, borrow, and steal someone in a different department. You can say, can we have them for even two weeks, three weeks, so that we could get this thing done and not sit there and wait. Whatever we can do to get the right people on the bus for moving at speed, you know, with ease and grace, you know, on this project, that's what we're going to go for. Not so easy because there's a lot of territory. There's a lot of territorialism and people don't want their people sidelined on something. But that brings it back to the organization itself, which is what does the organization really need to be doing? And what can they say no to? Steve Jobs apparently used to say to Sir Jony Ive, you know, the hardware and master designer, he'd say, what have you been saying no to, Johnny? What is the thing that you really, really want to do, but you're still saying no to because we're working on this other thing? Most companies don't do that. So that gets back to this. If they're too busy doing too many things, it's very hard. You even have a cross-functional team because each team's off doing all their stuff. It can't prioritize one team kicking ass on something important.
Melissa - 00:32:39: I get this question a lot and I'm curious what your advice is for it. I get a lot of product managers who write in and say, we start off with the best intentions where we build a strategy, we commit to a few things, we say no to a bunch of stuff, and then we get going with the year and our executives just pile more and more and more stuff onto us. And us as teams, you know, we're like, we can't handle this. We're trying to push back, but it's not effective. If you're a team member and not a leader with like that power, right? It's always great if you're the person in charge and you can witness that and prevent it from happening. But if you're a team member, what can you do when you see the company going towards busyness, taking on too much, people aren't allowed to say no, like how do you effectively push back and redirect?
Joshua - 00:33:26: I find that, first of all, it's extremely hard because you can do all kinds of things. I love to visualize the work, right? That's another lean concept. Visualize the work. Visualize the delays that are occurring because you're doing too many initiatives at once. We had a customer that was, I think they were doing nine different initiatives with about 30 people. And we would talk to their managers there and they were like, look, you're doing too many things. We know that. We know that, Josh. But our upper level executives who are in a different country, they're just constantly pushing stuff down on us. And so they felt helpless. So at that point, I felt the best thing we could do would be to sort of get those high level executives into a simulation where they can experience how horrible it is to try to juggle nine different balls at once, right? Or, you know, simulations and games, we love them because they can really give people experiential learning. And so, but an employee can't do that, right? I mean, outside consultants might be able to get away. The best I think they can do is try to visualize the damage being done by trying to do too many things at once. If they can show it somehow or another. I once took a video of a 28 page method function. It's 28 pages long. Incredible complexity. So hard because the executives didn't understand what they'd built over 10 years. It was this very complicated code base and you couldn't do anything in it. It was crashing all the time. But the only way I could get through to them was to just try to somehow visualize the pain. And so I made this video, this long method, and that seemed to work. It got some attention and suddenly we were able to like focus on fixing technical debt. So to me, visualizing the problems is the art in some ways of helping to convince people when they're doing silly stuff.
Melissa - 00:35:08: You know, it's funny too. It made me start thinking about like, I know we don't love Gantt charts and product management, but one way I feel like you could show people this too is show them how much longer everything is going to take because you put too many things on the plate. Right. And say, okay, if we do it this way, you know, maybe we'll have it done by Q2 next year. But if we do this as well, I've got to pull two developers off that other one. So you're not going to get that initiative until Q4 of 2023. Like, so which one do you want that out faster? And then we'll start the next one. Or do you want one over there? And timelines could be your friend in that case, instead of the commitment problem.
Joshua - 00:35:45: That's a great use of a Gantt chart. And not only is it like, are you going to deliver on those dates that are so late, but you're going to deliver poorly because people are rushing and hurrying back to be quick, but don't hurry. They're going to deliver on the dates. They're going to be really late. And then they're going to be filled with defects so that there's a ton of maintenance work. You lose. The best companies are really able to focus and just have the right amount of work and the right priorities. Do you see that in your work, Melissa?
Melissa - 00:36:10: Yeah, totally. And I was going to ask you, like, in your perspective, because a lot of people ask for these, what are some companies or a company that you think does that really well, that focuses, doubles down, says no, and kind of clears their path to work on the most important things?
Joshua - 00:36:25: I don't know firsthand in terms of what I understood from Apple is that they try to do that. I'd say that from the outside, it seems like they're pretty good at that. Oh, it's always hard to say, right? A lot of these large companies that people love so much, when you really get into them, you see that things aren't as rosy as you thought. I think all companies struggle with it. I think they might have a year or two where they're really good at it, and then new management comes along, and then they're really poor at it for some time. So I look at my own company. I'm like, well, how are we doing with that? Sometimes we're good. Sometimes we're not so good. The garden gets untended, and there's all these things that start popping up. Did you say no enough? So I guess I can't really give one particular answer to that in terms of a company. But to me, it's one of the most important things that leaders have to do is to cut back to the most essential things and do those really well.
Melissa - 00:37:16: I've seen that too. I get asked for examples all the time and I'm like, I can give you examples, but it won't be that this company has done this perfectly forever. It was like for a period of three years, let's say three to five years, they were killing it. And then sometimes they just slip back into old habits or something happens where management changes over, they scale too quickly or things were popping up because everything was so rosy that nobody was really paying attention to the fires that were happening around it. And I think that happens a lot. And I think that happens a lot in cases of doing product management well in certain parts, doing agility well in certain areas. And there's probably like tons of examples of like a moment in time when a company was like kicking ass and taking names, right? And then if you went into it today, you'd be like, what? This is not what you described, right? Like this is not there. And that's what makes it so hard, I think, to give examples of these because I'm like, oh, if I say that now, that's like how they operated five years ago. And I knew they were doing great then. But I don't know what they look like now. I haven't touched it in there. And that's what I find hard about those things.
Joshua - 00:38:19: That's right. And the stories I tell in my book are really instances in time of agility. They're not, hey, this company's always Agile. They're just moments in time that we're celebrating. So I believe it's important to celebrate real agility and stories of real agility, whether it was, hey, we invalidated a feature and we didn't build it, and that saved us a tremendous amount of time. It made us go faster. Wonderful. Let's celebrate that. You make a good point because it's like, why don't we celebrate the major successes of the company from the past, right? Highlight those moments so we can be more like that today. Don't do that enough.
Melissa - 00:38:49: I like that. And one of the things that popped up in your book for me that I wanted to talk about a little bit was the American Airlines story, because you talked about how they became Agile during Covid. And they had to, on the turn of a dime, be able to ask people, you know, had they been in China, and it was really hard to deploy that to their system. So there's a great story in there about it. I think we saw during Covid, a ton of companies, a ton of really big companies to become Agile, like overnight. But three years later, I see a lot of them no longer be Agile, right? Or they're not keeping up with it. Have you seen that too? And why do you think companies like can pull it together in a crisis and become Agile and then just forget about it right after?
Joshua - 00:39:30: I think it's in a crisis, there's one priority, which is to fix the crisis. And so it's really clear everyone can be super aligned. At American Airlines, it was 60 or 70 people over one weekend. The end of the prior week, they were told, you must ask every passenger if they have visited China. This is talking February of or January, February of 2020. So basically, they had a weekend to do this, to change their systems, to ask someone, any traveler, did you go to China? You know, 60, 70 people across many different departments working together, having large phone calls together and getting the work done. And they did it. They just did it. This is very clear priority. And so you see this all the time when there's a catastrophe or problem, people rally together, they work together well, it's awesome. Then we say, why isn't it like this all the time? And I think it's, again, it comes right back to, well, we have 20 different things we're doing. And so those teams are doing these things. This one team's doing five of those 20 things in there. They're multitasking their brains out. It leads to mediocrity. It leads to all kinds of problems. So the hardest thing to do is to say no to a bunch of stuff or not right now to a bunch of stuff and just focus on the things that are super important. To me, that's like the beginning of where you need to be.
Melissa - 00:40:45: I think it all comes back to that priorities. I like how these are all wrapping back into each other. So if we can limit our priorities, limit our work in progress, that can help us be more Agile is what I'm getting out of here.
Joshua - 00:40:56: That's right. And we're working with a client right now where it's interesting how they say telling people to limit work in progress is not going to fly around here. It doesn't fly. People don't get it. So what this woman was telling me is she knows the culture really well. And she says, what really works for people is talk dollars. What is the highest value thing to work on now? And what should be held off? Because it's not so high value. So it's a different way of saying the same thing. It's a more financially focused way of saying it. But I found that was very, very helpful because for a lot of people, limiting work in progress, it just falls on deaf ears. It doesn't translate. But if you say, what's the most valuable thing this company could be doing and what's not so valuable and that could be paused or pushed out, that's saying the same thing, right? Let's prioritize the high value work and work on that. I'm always learning. And that was a very nice little thing that happened this week. We're not going to use the limit work in progress language anymore. We're going to use it in a financial context and talk about value.
Melissa - 00:41:52: Is the only way I have found that works with executives too. And that's like how I have to speak to any CEO or CPO. And that's what I trained my CPOs to do. I'm like, if you want to, if you want them to choose what you need to work on, you bring it back to how much money it's going to make or how much money it's not going to make and which one's going to be more important than the other. And you can find that the executives will. Change your tune very quickly about what they want prioritized then. So I love that advice. So for you, when you're looking at Agile for the next 10 years, what do you think's in store?
Joshua - 00:42:24: I was inspired a lot by this book, the Lives of the Stoics by Ryan Holiday. And you look at the Stoics, their Stoicism matured over many decades, hundreds of years. It didn't just happen in a short period of time. It took other leaders to come along and other people come along to help refine it and simplify it and maybe further explain it for people. So to me, Agile could easily just become this fad that dies, right? The rationally unified process was hot and heavy in the 90s and then came and went. There's been all kinds of movements within software space. I'm going to work really hard to get people to stop thinking of Agile synonymously with software. I kind of love history and I love to learn about earlier things. So there was this group in the early 90s, like 1991, that was focused on Agile Manufacturing They used the term Agile Manufacturing. They were looking at what Agile meant back then and how they could apply It was a huge movement. I mean, the Government, use government funded it. There were 150 companies involved in it. This was a really big response to what was happening in America around manufacturing, especially with vehicles, compared to Japan. Japan was kicking butt in the 80s, right? Something had to be done. And so Agile Manufacturing came around. People don't even know this. They believe it all began in 2001 with the Agile manifesto. And that is true, okay, for software development. But what I've seen is just that to be effective in these organizations, you cannot just focus on software development agility. You have to be whole organizational agility, as we've been talking about. So to me, the future is those brave souls who are willing to like look at the last 20 years as the early days of Agile. And move forward with it to say, great, now how can we really mature this and make it something that organizations can really benefit from so they're not ticking little boxes for what framework they're supposed to be using or this or that. They're not treating it like a little recipe and they're using their brains and they're trying to apply these concepts. I'd love it if the mantras became more popular because I think they're so valuable. But I think there's lots of others who are writing books and trying to pursue this. And agility, hopefully agility has a long future ahead of it and a valuable future ahead of it. And we can stop thinking of it as there's the Agile box. No, agility is the ability to move with quick, easy grace, to be quick, resourceful, and adaptable. We all want that. How can we make that happen? What do we need to learn to do it?
Melissa - 00:44:56: I really hope we get to that place because I think it's going to help so many organizations. So thank you so much, Joshua, for being on the podcast. If people want to go buy your book, where can they go? Buy the Joy of Agility.
Joshua - 00:45:09: We can buy it at all major booksellers. There's an audio edition that I actually self-narrated. So that's really fun to do as well. But any major bookseller has the book now. You can even get it in the library. If you don't want to pay any money, don't have any money to spend, go to the library. It's there too. A lot of people have told me they've been reading it in the library. So you can go to joyofagility.com. you can download a free chapter. And I'm playing around with the idea of having a book group, a study group on Joy of Agility and other books. So that's potentially coming as well.
Melissa - 00:45:38: Love that. And if people want to connect with you or learn more about you, where can they go?
Joshua - 00:45:42: They can go to industriallogic.com. We have a people page and they can, you know, click there and send me a message or find me on LinkedIn. I'm often on LinkedIn these days. Probably those two places.
Melissa - 00:45:53: Well, we will definitely put in our show notes all the links there so that you can go buy Joshua's book and you can connect with him. Thanks again, Joshua, for being on the podcast. And thank you all for listening to the Product Thinking podcast. If you enjoyed this episode, we would love for you to hit that subscribe link. And then you will never miss an episode. And we'll be back next Wednesday with another guest. We'll see you then.