Page to Practice
Every month, Paul Klipp interviews another author in the agile or product space to learn how you can apply their latest ideas in practice to efficiently build effective products.
Page to Practice
#20 Joy of Agility with Joshua Keriewsky part two
Agility is not just a methodology; it’s a collection of principles that emerge from real-world practices. Joshua Kiria discusses the evolution of six key mantras that facilitate agility in organizations, emphasizing balance, psychological safety, and the harmony between speed and quality.
• Exploration of six mantras for achieving agility
• Insight into how the mantras emerged from practical stories
• Importance of balance between delivery and discovery
• Concept of grace in agile practices
• Navigating the tension between speed and quality
• Psychological safety as a foundation for team empowerment
• Challenges of maintaining long-term focus in a short-term driven business world
Thank you. Go back and listen to that. First. In this half of the interview, we go a bit deeper into the actual content of the book. Now, if you haven't read the book, you'll be able to follow this conversation just fine. But if you have read the book, you'll be able to see what it was that inspired these questions and why I wanted to dig deeper into these particular areas. We have a wonderful conversation ahead. I'm sure you're going to enjoy it. I thoroughly enjoyed it. I'm going to keep the intro short this time because we've got a somewhat longer episode today, so let's just jump right into it, the second half of my interview with Joshua Kiria. You sum up agility in six mantras.
Joshua:How did you come by those. Yeah, I mean, I'd say the six mantras were not at all in my vocabulary when I started writing the book. They came out of having to organize a bunch of stories into a book. That's really what led to them. And, um, you know you, just you look at different stories, you read them and you say where does this fit? Like what, what? What section is this going to? What is this really trying to tell us? Um, and you know, I the book is very focused on the words in the definition of agile words like quick, words like adaptable and words like resourceful.
Joshua:Those are really important words, um. And then you know there's other words like grace, you know, um, having an ability to move with quick, easy, grace are the definition. What does that word grace mean? What does it mean to be graceful? And then why is it that balance is so important to grace and to speed? You know that became really clear from my research, especially of John Wooden and his team. He was obsessed with balance. Why was that? And what does that have to do with being graceful or being quick and not hurrying? And so there were these words that were so important.
Joshua:And then there were the stories and I had to sort of bring them together, right the stories and the definition, and kind of put a structure in place. And so gradually I started to see, you know, a good number of these stories really fit into this concept of being quick without hurrying, like Slack from Tom DeMarco, a classic book that everyone ought to read. And I'm not talking about the tool called Slack, I'm talking about the book. And he literally says that the companies he admires the most are companies that don't hurry all the time and that do amazing things. But there's no sense of like hurry, it's, it's a very, you know, calm place where great work gets done.
Joshua:Well, that story fit into the be quick but don't hurry, uh, mantra. And even the word mantra is not something I was using a lot before writing the book, but Paul O'Neill would call them mantras Sorry, not Paul O'Neill, I meant to say John Wooden. John Wooden called them mantras for his team. So the mantra be quick but don't hurry was something he used every single day. The players would say he uses it many times per day. He drills it into our head. It's such an important concept for him, it's a mantra, uh, actively using it every day. So the murder mantra came along and so, gradually, I pulled all the different stories into the six buckets and it took months and months to figure out what were the right needs for those, for those mantras, especially the be balanced and graceful one. That was easier said than done in terms of coming up with that one it was. It went by other names and it morphed and changed and eventually became that now I'm going to explore that a little bit more with you.
Paul:But one of the things that I like about this story is that I think it lends a lot of credibility to a theory if the theory emerges from the evidence. You start with a collection of stories of success and what emerges from these stories is a set of principles which happen to align very closely with the principles behind the Agile Manifesto. It suggests that you're not starting with a preconceived idea and trying to find things that fit into your boxes, but this is actually a thing which is present in the world and it can be extrapolated from the data of success.
Joshua:Yeah, that's very well said, and it felt like a discovery to me in terms of just like didn't realize that these things were there and I cherish them now. I mean, I do cherish those mantras in terms of helping me to be agile and reminding me of when I'm not being agile. Going back to them Am I being resourceful, readily, readily, resourceful, readily is a very ambitious word. It means easily and quickly resourceful, without thinking, boom, you're readily resourceful. They're inspirational and they're high bars. They're not as if you accomplish each mantra, it's something to practice and work at every day. But yeah, they were a gift of writing the book that emerged.
Paul:I'm a big fan of evolutionary and emergent design, so it was nice to see something emerge out of the writing process that became powerful, going back to balanced and great, because that's very interesting, regardless of, most listeners here are going to be in the software industry, and one of the things about software is that it has very few constraints to getting in front of the customer, unlike other products and services, and because of that lack of constraint, there's always this pressure. Even if there's not an existential crisis, there is lost opportunity for every moment that value isn't being delivered, and so almost everyone working in software is under constant pressure to deliver faster. So what does balance and rate look like in a high-pressure, fast-paced environment?
Joshua:Yeah, great question. Well, first of all, you need to look at different practices, different activities that you know may have value, for example, speaking with customers, observing customers, spending time understanding their problems, if you just hurry up and push something out there. So you're kind of like, in terms of balance, you're kind of tipping the scales towards delivery and maybe not putting as much weight on discovery. You know your delivery is the focus, right. You're kind of out of balance between discovery and delivery and you may suffer from that because the balance there isn't as good as it needs to be. I myself shipped software where we didn't have usage metrics.
Joshua:Now, if you ship something without usage metrics, you don't know what's being used and what's not being used. You're flying blind. You have not got the right balance there of you know simply even learning between doing and learning. You're doing, you're doing, you're pushing stuff out Great, but are you learning about what you pushed out there? The balance is off and what you know John Wooden would say is, when your balance is off, you're actually hurrying and you're rushing and you might think you're being a hero, but that's not a consistent way for being a champion If you're a UCLA Bruin, but I believe it applies to business too. You've got to find the right balance in things, be aware of what those balances are, in order to have long-term success. You know that's not easy and grace.
Paul:What is?
Joshua:grace. Grace is well, if you look at the definition of grace, there's numerous definitions, but ultimately the one that really fits here is about being supple, and if you look at the word supple, it means that's adaptive. And if you look at the word supple, it means that's adaptive. So really being graceful means like, let's say, you're walking through a kind of obstacle-strewn environment and you're gracefully walking through it, right, you're adapting to the situation and able to just move easily and without problem, gracefully handling challenges. It's ultimately, I think, about being calm and being adaptive and being skilled enough to handle tricky situations. There's a story of a woman that I respect quite a bit named Catherine Thalheimer, and she gracefully handled a pretty ugly situation where folks came to work one day and all the posters that we had put up for many teams these are iteration posters and planning posters and all kinds of posters. In Agile we make a lot of posters. There's a lot of stuff on the walls. Imagine one day you come to the office and they've all been taken down. Wow, that's a shock. And when they found out that the custodial staff didn't do it and they pretty much knew they didn't do it because those folks knew not to take that stuff down, some sabotage occurred, something very screwed up occurred there, and this was part of a push to bring agility to an entire division.
Joshua:A lot of people I myself, when I heard this was angry. A lot of people were angry. You know who did this and how can we, you know, punish them or, or you know, do something, some kind of retribution, something? Catherine being the director of the division, she was able to sort of be calm, assess the situation, do a little research and discovered you know, we're not going to find out who did this, but she said to the whole group yeah, this happened and, um, we are just going to move on and continue doing what we're doing with the agile and maybe you could keep a little more digital records of what you have. But, uh, let's keep going. You know, we don't. We don't know who, who did it. We're not going to keep searching.
Paul:No-transcript very nice story. Yes, I'm into it. So the other challenge with speed and that's quality. You and I were both in software before Agile and so you'll remember that when you're building using waterfall, your buffer is at the end and it's called testing and you can always cut into it because people are optimistic, it's not going to be that bad, they're not going to find that much. If we just cut a week in a couple more into testing, we'll be able to absorb it there and we would have thought that would be over with Agile, now that we're working in short iterations. But there's still a conflict between speed and quality, where it is generally perceived that quality has to give in order to deliver speed, and I believe this is a false dichotomy. I think you believe this is a false dichotomy. How do you describe that false dichotomy between speed and quality to somebody who is just delivery focused?
Joshua:Yeah, it's a great question. I think the long-term speed comes from a quality approach. It comes from taking care of your code base in a way that is financially responsible. So it's irresponsible to make a mess and just expect that things are going to be fine with that mess when in fact the evidence shows that there's mounting defects. There's tons of rework because things are broken and we have to fix them. You're spending more time fixing things than making things. If you start to just look at the evidence, it can clearly show a poor strategy.
Joshua:With respect to balancing speed and quality. Um, they're not, to me, separate things. I would say you know, are you rushing? If you're rushing, um, that's where you make mistakes, right? You know, I always say speed and quality of speed, speed and quickness are always wonderful. I to me those words. I never try to use the words quickness or speed in a negative context. On the other hand, I'll use rushing and hurrying in that negative context, because when you're rushing and hurrying, that's when you're making costly mistakes, worrying, that's when you're making costly mistakes and those mistakes are potentially going to really hurt you, either short term or long term. They will really hurt you and uh.
Joshua:So again, it comes down to balance, because you cannot have speed without balance. So it's a question of what are you balancing here? Is there enough quality in order to ship without having so much rework and so much waste? Again, we aren't interested in waste, we are interested in learning. You can learn from mistakes. I'm not saying don't ever make mistakes, right, you learn from mistakes. But it's not a question of learning.
Joshua:When you see a continuous pattern of, you know, poor quality work, that's, that's like well, okay, let's, let's step back and say we're shipping poor quality and it's slowing us down, it's bothering our customers, giving us a bad reputation, it's making work kind of not very fun. And these are signs that we could improve. We could improve in our. Maybe we're just going too fast and not putting enough balance on quality. What quality practices do we need to start learning about? And then it can also come down to like the, the notion that the more features the better, so the more we ship, the better off we are, and that may be, you know, misconceived in terms of direction all right, I want to talk about psychological safety.
Paul:I would be remiss to leave it out of this interview, because you write about it so much in this book that psychological safety probably comes up as often outside of the driving out fear chapter as it does in the driving out fear chapter. It seems to be underpinning so many of the other mantras. But I've got a difficult question that I ask everyone who writes and talks about psychological safety on this podcast, and that is have you ever seen it at scale? Can a corporation actually foster a management culture that encourages psychological safety?
Joshua:The only place that I've really seen it is Alcoa, and that's the company that Paul O'Neill ran for 13 years. Paul O'Neill comes up quite a bit in the book. He's a hero of mine and he's the one that opened my eyes so much to the kind of doorway to excellence, if you will, that is safety now for him. It was the kind of doorway to excellence, if you will, that is safety Now for him. It was very much about physical safety within these aluminum plants. He was the CEO of Alcoa, the aluminum company of America, which is an international organization with plants all around the world. But I asked him about psychological safety too. I asked him about that and you know he created an environment that empowered people to speak up. His first days as CEO he went to every plant and said listen, this is the thing. Safety is critical now. This isn't the latest priority of the company, this is a prerequisite, and if your manager is asking you to do something that puts you in harm's way, that is going to hurt you, you must speak up. And in fact, if your manager doesn't listen to you, here is my phone number Call me, I will help you. Now, that is right. Empowering people to speak up to disagree with a manager. And that is that start.
Joshua:So that physical safety begins with psychological safety, because you have to give people the. They have to believe that their voice matters and that. You know Amy talks about voice over silence. It's easier to be silent, right? A lot of the times. Why should I speak up and put my neck on the line? I'll just be quiet, right? Safer for me. There's immediate personal benefit If I say stay quiet, I'm not risking anything, right?
Joshua:But what Paul O'Neill did was he said I need you to do this and you're safe to do this. Speak up. He gave people voice. So that to me, um, and he did it at scale. There's no question that all across Alcoa people were. They believed in what Paul was saying, they believed in speaking up and they did speak up and the place transformed. It totally transformed, because people were able to speak up about safety issues. They were able to even come up with innovative ideas for solving the safety problem. But again, we can think of that as physical safety, but I believe it started with that psychological assurance that it's okay to speak up and in fact I'm encouraged to do it here.
Paul:I'd be very interested to know and perhaps this came up in your conversation with him, because I've never met him and once every single individual in the organization knows that they can safely speak up, even challenge conventional practices or challenge management, on this particular topic, this one topic of physical safety, does that also lead to an environment in which they feel comfortable speaking up about other things?
Joshua:it did it did it absolutely. In fact, it led to them being um more comfortable to suggest better ways to work that weren't so much about safety, they were about. You know, it's kind of inefficient to have this machine over there and that machine over there, and if we just brought them closer together we would be more efficient. It's not necessarily going to make them safer, but it's going to make them more efficient, and they were. You know the stories that came out and I interviewed one of his chief lieutenants and and I interviewed him twice, um again, you know, because I was just so enthusiastic about what he did he took a 100 year old company when he took the helm in 1986.
Joshua:Um, alcohol was 100 years old. They had invented the aluminum smelting process in 1886. Back then, aluminum was a very specialty thing that only the wealthiest people in the world had access to. They invented this smelting process for aluminum that transformed things. 100 years later. They were struggling as a company. They were, uh, having a lot of problems with competitors, with lack of innovation, with terrible problems with unions, um, just on and on, tons of problems. Paul o'neill brilliantly restored them to their grandeur and their greatness. Just brilliantly. He did that with safety To me. That's my paradigm of psychological safety at scale.
Paul:You know this is a pattern that I've seen in successful CEOs is so often what makes a successful CEO especially a transformational CEO successful is their ability to put their finger on one thing and focus on it, and just keep focusing on it long enough to drive change there and all the other changes that have to happen flow from that yes, very well, said paul.
Joshua:I mean, um, that you know when? Well, what I heard was that when, when paul neal first took the helm there as ceo and started talking about worker safety. You know the story is, uh, is told by charles duhigg in the book the Power of Habit. That's where I first encountered the story of Paul O'Neill. It's called the Ballad of Paul O'Neill, the chapter in the Power of Habit.
Joshua:You know most people thought well, you know, he's talking about worker safety. First of all, wall Street said sell the stock. They hired a crazy person. He's talking about worker safety. Nobody talks about worker safety. Ceos talk about not paying taxes and, you know, ramping up production and blah, blah, blah. They don't talk about worker safety. So, this guy's crazy. A lot of people said sell the stock, which would have been a terrible idea. And basically they said well, he's going to talk about worker safety for a few months and then he's going to shift to something else. So you know what, don't take it too seriously they were dead wrong, dead wrong. He was completely focused on this worker safety thing for years and years and years and he would say it's not a priority, because priorities shift with the winds, it's a prerequisite and that inspired the modern agile principle make safety a prerequisite. That's Paul O'Neill.
Paul:You know, and that brings us to the point that I told you we'd come back to in the second half of the interview. In the first half of the interview you mentioned that so much of Agile is just an Agile action, something that happens in the book. Now they're Agile. Tomorrow they might not be Agile. They're usually Agile but it's always Agile. That was an Agile thing, but this isn't an Agile company. But when I was reading the book and there's 70-odd stories in here one of the patterns that I saw is that a lot of the examples of agility were exactly that of time, like a new developer intern pushing code to production on their first day, or a designer having an idea to capitalize on a moment when the lights went off in the auditorium during a big sports game or something, and it had to happen in that moment. But the story beneath this story is that in all of these instances, an enormous amount of groundwork went into creating the culture and infrastructure that had to be in place to allow that to happen.
Paul:And companies, especially any publicly held company, is driven by quarterly returns. They have to keep the shareholders happy, and you've said in this book as well that an agile transformation, a real agile change, takes years. So how do you convince executives in a corporation that have to keep the analysts happy quarter on quarter to invest in the years of work in order to create an environment in which these spontaneous, wonderful things can happen?
Joshua:A wonderful question. I think you know it's. Let me step back for a second and just say I just want to highlight a story, which is this happened at an automotive company. It happened with an industrial logic team of highly experienced software practitioners. So, going back to like experience, highly experienced software practitioners are a different breed, because if you give them a requirement, they may not just implement it. I might think about it and say this doesn't make any sense. This is going to take us a long time to do, and in fact, we could just accomplish this in a much simpler way.
Joshua:And that happened on a project at this automotive company, and the developers just said you know what, instead of creating all these screens, we're just going to give the uh, the user a spreadsheet with the data that they want and see what happens and measure usage of this. And the product owner said absolutely not. And they went ahead and did it happens and measure usage of this. And the product owner said absolutely not. And they went ahead and did it anyway and they got some usage metrics and the customers loved it. It took a tiny amount of time to do. Now, how did this occur? There were some ripples and ramifications of disobeying the product owner, but the company got what it needed. The users got really what they needed. They were joyful to get this solution. And if you say, how did this happen? Well, it took years of these veterans becoming veterans in order to see that simpler way of executing on that need, instead of just blindly following the requirement. They saw a much faster way to deliver. Now, if you multiply that story the way we just talked about Paul O'Neill and his safety, multiply, right, because that multiplied and changed the entire organization. Right, it transformed a 100-year-old company that was in, you know, a big, you know really screwed up, having tremendous problems, transformed them Great. So if you take these stories of skilled workers working in a much smarter way, that is more, that has quality and speed with it, multiply that across the whole organization, suddenly you know you're going to see multiplier effects and that, to me, is is where a smart organization would go. They want to be around for a while and want to do some great things.
Joshua:Is there going to see the need to play the long game, create the culture that allows for amazing things to happen and isn't always so short-term focused? That's not necessarily addressing your question about wall street, right, because wall street does like to see things and we see we have customers that they are so reactive to a couple of bad quarters you know, where, all of a sudden, something they invested in, maybe even millions of dollars, goes by the wayside because all of a sudden the stock's not doing well. It's a short-term focus that hurts them right. I know Eric Ries has been working on something called the long-term stock exchange, because this problem at Wall Street of just focusing every quarter and looking at companies' results doesn't always lead to the smartest behavior. You need a lot of fortitude to stick to your guns, even when the stock's not doing too well, if you know that the long-term direction is good. So I guess I don't have a great answer. Maybe in some respects I'd say I am usually playing the long game, but not every company cares about the long game. I've learned this over the years. There are some companies that just care about the short term.
Joshua:We worked with one company years ago as a io informatics company. They wanted us to help them with some agile things. We went in there and did some some good work. Pretty soon after they they got bought by another company and I talked to someone who uh, you know, used to work, work there, and he said, yeah, they got bought, and one of the reasons that the company acquired them was their knowledge of Agile. And it turns out that they wanted to have us help them with Agile because that was a little more lipstick to put on the company as they were trying to get acquired. So it was really just part of the acquisition strategy was to have a little agility mixed in there so that the company could acquire that too, and that was so. It really wasn't about becoming more agile, it was about how do we make ourselves look, you know, good enough to be acquired? Great.
Paul:I think you did stumble across and answer my question there when you used the word balance. Great, I think you did stumble across an answer to my question there when you used the word balance. At least one answer to the question is that this could be. Another aspect of balance is balancing the board from the one.
Joshua:Yes, well, that's very well said. Again, yeah, that's balance comes back to so many things if you really think about it. That's why John Wooden was so focused on it Offensive balance, defensive balance, height balance on and on. He just kept going. That takes a lot of wisdom to appreciate balance for what it provides you in terms of overall benefits and speed.
Joshua:You know, not every executive is gonna, is aware of this and has the fortitude to stick to uh, a long and a short-term. You know goals and hold both together at the same time. Um, you know, I think the best ones do. I mean, you know Amazon didn't care so much about a bad quarter or about not even making profits. For years. It would be like Amazon hasn't made any profits. I made more money in industrial logic than Amazon made and they lost money, but they're building this giant thing. That was definitely future oriented. I'm not saying they're a perfect company. No company is perfect. That was definitely future-oriented. I'm not saying they're a perfect company. No company's perfect. Every company we can find flaws in. But yeah, it's tricky to balance anything and balancing long- and short-term goals is very difficult.
Paul:So there you have it. That was my interview with Joshua Kerievsky. If you are intrigued, there'll be a link to buy the book in the show notes. I think you'll enjoy it. I certainly did.
Paul:And tune in in two weeks when I'm going to be talking to Erin Weigel about her newest book to come out of one of my favorite publishers, rosenfeld Media Design for Impact your Guide to Designing Effective Product Experiments. One of my favorite publishers, rosenfeld Media Design for Impact, your guide to designing effective product experiments. Now, I know this is something that we all struggle with. Experiments are tricky, experiments are expensive, we don't have time for experiments, and so I haven't read this book yet, but I'm very keen to. You know, I trust everything that comes out of Rosenfeld Media. They do a great job of finding industry specialists and working with them to create wonderful, wonderful books, so I know it's going to be a treat. I'm reading it this weekend and interviewing the author next week. I'm very excited, and you can hear that interview on the 1st of March right here at the Page to Practice podcast. See you there.
