This is a transcript of episode 232 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Squirrel and Jeffrey trade stories about tech organisations who are effectively improving incrementally – and examples of those who are just doing and not learning. Rother’s Coaching Kata and Torres’s Opportunity Solution Tree prove helpful in illustrating how to shift to this mindset.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:11
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi Squirrel.
Squirrel: So you heard something new, exciting, and different about kaizen, a topic that some of our listeners will know of and some of them won’t even be able to spell.
Jeffrey: Yeah! Kaizen is a Japanese term meaning “change for good.” It came up because we had one of our monthly discussion sessions today, where we have some study group topic such as some advanced reading or in this case a video, and we discuss what it meant. If we agree with it, we also discuss how we would apply it? It was really funny because we had a group of people who all had some passing knowledge of kaizen, so everyone came in and said, “Well, yeah we know what kaizen is. It’s continuous improvement, and we think it’s great.” But the funny thing was when we got into discussing it, different people had different ideas of it. This gave me kind of an “aha” moment about some of the disagreements I had with people: I think kaizen has the spirit of continuous improvement, making even small improvements continuously add up to big differences over time. In that sense, kaizen is like a habit that you’re always applying, always looking for places to improve. But for some people when they gave examples of kaizen, I would say they were more about incremental execution rather than incremental improvement. An example analogy someone used was “if you have a bunch of dishes to wash and you don’t have time to do all of them, at least wash one dish because at least things are better.”
Better at What?
Listen to this section at 02:07
Squirrel: This analogy just drives me bananas. You were telling me about this before. I think that somebody is really missing something here.
Jeffrey: Exactly. So this question “what is kaizen” seemed relevant because even people who are fans of it and like the idea struggle a bit about how to improve with it, and it occurred to me that actually a lot of our listeners have probably experienced places where kaizen goes wrong, because I think very often if you look at the way a normal team would work, especially an Agile team, you have many rituals that are there to help support continuous improvement, but that people don’t know what they’re there for and they don’t use them. Examples that come to mind are stand ups and retros. In particular, sometimes there’s only focus on execution there and not on learning. So someone might say, “oh, that thing I was going to do yesterday, I didn’t finish it, but I’ll finish it today.” What I would hope for would be recognition that there’s an opportunity for learning; we had an expectation and things didn’t go as planned. What did we learn from it? That could be great.
Squirrel: And then how are we going to act differently as a result of what we learned?
Jeffrey: Exactly. But there’s no appetite for that, so often the question that comes up in response is just like, “well, when will it be done? If you didn’t get it done, when it will be finished,” or even worse as you said, there’s no questions at all. People just go, “Hmm, okay.”
Squirrel: “We’ll move that down.”
Jeffrey: Yeah. “I guess the card stays in the same place on the board. Move on to next.” There’s this opportunity for reflection and improvement, but it doesn’t happen. I think that’s why often retros are so lifeless. A lot of times in retrospectives people will say, “we’re making this change because we think it’ll make an improvement.” But then there’s no accountability. They don’t come back later in the next retro and say, “Hey, that thing we did, how did it work out? Did we did we get the benefit?”
Squirrel: That’s why I always say the most important part of any retrospective is the reflection on the actions from the last retrospective, which you should always do first.
Jeffrey: That’s right.
Squirrel: Because that’s where you get the chance to reflect the learning.
Jeffrey: Exactly. We don’t know that we’ve actually achieved the improvement unless we check to see we actually improved it. So often people think they’re doing improvements because they’re making changes that they predict will be an improvement, but they’re not actually checking that they did improve, and this is the difference between in kaizen, often described as having the PDCA cycle—plan do check act—but instead people are just going plan, do, plan, do. “I think this is an improvement, I plan this improvement. Let’s do it. Plan the improvement. Do it.” But they’re not actually following through and checking the result and this pattern of plan-do instead of plan-do-check-act I see showing up all over the place.
Squirrel: Absolutely. I had two examples of this recently. I had someone telling me “our team doesn’t believe in lots of meetings. So we’ve cancelled all our stand ups.” I said “Hang on a second. There’s something that doesn’t add up. I can tell you that when I have stand ups in teams, that results in fewer meetings; it concentrates more of the learning to the stand up.” And he said, “Oh, that’s not our experience. We aren’t going to do it.” So I said, “Well, let me know how that works out for you. If it’s successful, great. But I predict that you’re going to have some trouble,” because the stand up should be exactly where you capture learning and discover something that is different. It should be a locus for check, and act. I think the difficulty is that if you’re only checking on what you planned and what you did, there’s no learning, and it can feel like just another meeting.
Jeffrey: Yeah.
Squirrel: Those should be different.
Jeffrey: That’s right. This is why I was interested in talking about this, this misunderstanding of what it means to actually be learning and improving I think is very common. The good part is that people have picked up the value of incrementalism, which is to say let’s do a small thing first and then we’ll see. The result is that gives many opportunities for learning. But again, I’m always struck that people aren’t taking those opportunities for learning.
Scrubbing Experiments
Listen to this section at 06:41
Squirrel: Yeah. And back to that dishes analogy, the problem that I have with it is that it mischaracterizes the nature of the activity. So I hope when you were planning out your strategic activities for the week or the month that you didn’t plan at 4:57 on Thursday you would do the dishes or something. You might have said, “we’re going to increase cleanliness in the office.” That would be an interesting strategy, and yes, you could act by washing one dish, but you could also reflect on how the heck did these dishes get here anyway? What’s wrong in our culture that’s causing people to leave dirty dishes around? That would be the checking and acting part of it. But the difficulty in the analogy, and often how people think about these things, is that they they think about the activity wrong. They think the activity that they’re going to plan and do is a mechanical act, a routine activity. It’s a thing that you know how to do and you won’t learn anything from, like washing a dish. Maybe you’ll use slightly better dish detergent or something. I doubt it. I think you would be much more likely to learn things like “Bob never does his dishes because he’s annoyed that he’s not paid enough, so he acts out.” That would be really valuable. That would be incredible learning that would help you in many areas. But slightly better wrist technique in drying dishes? Probably not. And that’s what I see a lot of people doing. The second example I have is one someone was explaining to me just today. This person is helping people in his organisation to think more in terms of hypotheses and experiments, and he used a nifty thing that I’ve not seen before called the Opportunity Solution Tree. What he had was people who had done a lot of research, who really understood the customer, who had tremendous opportunities that they’d identified. If you look at the visual, that set of opportunities comes at a certain level of the tree, and then below that branching off it are different solutions and experiments that prove which solutions are right, but the solution and the opportunity are different. He said he was able to use this visual to help others understand how they were framing the problem in a way that wasn’t helpful. They were framing the challenge to tech: “how can you plan and do…the thing that we’ve already researched and the information we have.” And when technology folks would come back and say, “well, we’re going to do this series of experiments.” “Oh, my God, they’re revisiting everything! We just did this research! We know what to do! Would you please just do it?” And what he wanted to communicate was that the solutions and the experiments they were trialing were in order to realize the opportunity. The opportunity might be support certain kinds of single sign on, for example, so that certain customers can work with them. Well the opportunity was, “look, we want to log in once. We don’t want to remember a bunch of passwords and we’ll use your system more if you do that.” That opportunity isn’t going to change. But you can’t just plan and do that activity. You could, and that would be catastrophic. What you want to do is do the experiments, which will involve checking and acting about different types of single sign on, which customers want them, which ones are easy to implement, which ones work well with our system, which ones are deprecated and going to be out of support in two months? What are the different characteristics of the landscape that will then allow us to have the opportunity, which is users won’t have to use passwords anymore and it’s not throwing away the research which discovered that users hate passwords. We know that we’re not going to forget that. We’re not going to drop that and suddenly build a video game instead. But the point is the iterative process and building the hypotheses allows you to implement the opportunity. And he just found that really useful for explaining. I thought it was an insightful way of approaching exactly this problem.
But How?
Listen to this section at 10:49
Jeffrey: The key idea that I got from what you’re saying is that there’s this sort of allergy to experiments, the feeling that if we’re doing experiments, it means we don’t know anything, as opposed to experiments extending or building on what you’ve already known.
Squirrel: Yeah. Go, tell a scientist experiments mean you don’t know anything and then stand back. Because they’ll tell you: “What do you mean? We have notebooks full of hypotheses and ideas all of which build on the 17 notebooks we have that we did last week!”
Jeffrey: Yeah. I think it’s worth adding in that our discussion of kaizen, my critique of the video was, “yeah, this video was great and very inspiring about what kaizen is. But like a lot of advice out there, it doesn’t tell you how to do it.” So for people who think, “Oh, this continuous innovation stuff sounds good, I’d like to do it,” actually the resource I recommend is a book called The Toyota Kata, which I know we’ve mentioned before. The book has two different kata that you go through. One is the improvement kata, which is how you’re actually doing the improvement, and the other is the coaching kata, how you’re helping someone improve. In the coaching kata you’ll find this part where you’re asking the learner these questions: “what did you plan as your last step? What did you expect to happen? What actually happened, and what did you learn?” That examining, reflecting on the gap between what you expected and what actually happened as your source of learning is built into this. So when you come around to “how do we actually start doing this,” there’s a very good resource for beginning and you’ll find exactly when and how to be asking these key questions to make sure that your cycle is actually a cycle of plan-do-check-act that has built in reflection, as opposed to falling into the trap of plan-do-plan-do without ever actually getting the improvement.
Squirrel: The “act” is “act on the system.” The act is to change something about what you’re doing once you’ve learned. As one of our favorite authors Chris Argyris would say, it’s a double-loop learning. You’re learning about the system rather than learning what the system currently does, and then adjusting that. Thanks, Jeffrey.
Jeffrey: Thanks Squirrel.