Resilient Orginisational Design for this decade (Part 2)

Richard de Kock: 0:16

A big welcome back to part two of our two part session podcast with David J Anderson. If you missed the previous podcast, I highly recommend you listen to it in order to get the most out of our session today. You can find that at www. thesearchforclarity. c om or on your favorite podcast platform. As a summary from last week, we've learned the following we got an overview of the key publications you can read to start getting a deeper understanding of what David J Anderson's approach is, as well as how you can start putting that into practice. We also got a glimpse into how the CanBear movement has evolved today to a tool for evolutionary change for organizations to become more resilient. We learned about some of the challenges that leadership might be getting with adopting these kinds of practices and what they can start doing to focus more on success moving forward. This week we're having another jam-packed, exciting session where we're going to get deeper insights into what CanBand as a system is, but also we'll be getting to understand how David has woven together concepts such as service orientation and customer experience into this approach for organizational evolution and resilience. We'll also get an opportunity to start talking more practically about how organizations can take these ideas forward so that they can start getting the same success that David has been getting with organizations for all these years. Before we begin, I would just like to give you a gentle reminder that I am a full-time Microsoft employee and that this podcast and the ideas provided by our guests are in no way affiliated with Microsoft's business practices or services. With that, let's jump right back into the interview.

Richard de Kock: 1:53

I think what I found most profound about your work over the last 20 years is that you started off from a focus very much on the process, which is really around the CanBand side of things.

Richard de Kock: 2:07

How do we create flow? How do we get our teams to really lack of a better word just really enhance what they're doing and get to outcomes faster? Now you've brought in the service paradigm, but in the service design and management, but really more in the context of how do you deliver value customers. You've also now woven in customer experience paradigm in the context of knowing your customers but being more strategically competitive in meeting their needs. You've kind of encompassed, instead of just the one area which is traditionally, I think, where most of the agile approaches have stopped, just the process of things. You've expanded that to look at these other paradigms, to give you more of a holistic view of the organization and make sure that we're focusing on the right areas. When I read your work, I can pick up on that thinking already in 2010. I guess that's your point. You started to see that back in 2003, just before when you published your first book, right?

David Anderson: 3:14

Yes to what you said. Now, specifically, I made a strategic decision when I was writing the Kanban book to focus on the evolutionary change aspect. The reason for that was that there's a lot of people out there in love with their processes, their frameworks, their various doctrines that they might follow, that they might feel some tribal affiliation towards. The idea was to take somewhat of a Buddhist-style approach that you've got your own way of working right now. Well, let's accept that for what it is. If it's working for you all, well and good, or if it's sort of kind of working for you but it could be a bit better, why don't we try adding some Kanban in that environment and see if it will make it better? We're not trying to take anything away from what you're already doing. We're just trying to make the bits that you would like to be better, make them a bit better.

Richard de Kock: 4:19

In the word Kanban I mean in my mind I'm translating that to making your work visible. So, especially in a service-oriented environment, everything is non-tangible. Kanban is really just giving you a way of making your work more visible to make you more effective at managing and producing results from that work. Is it fair to make that association at a simple level at this date, to the word Kanban whenever we bring it up?

David Anderson: 4:44

It's good that you asked that. So for me, fundamentally, kanban is about Kanban systems and therefore virtual Kanban systems rather than physical ones that you might find in a factory where they're using physical tokens. So a Kanban system is about limiting work and progress and managing inventory and pooling work when you have free capacity. So Kanban is fundamentally about inventory control and flow and visualization. Yes, if you Google translate Kanban, you'll find something like 16 different translations in Japanese and, depending on how it's written, you can write Kanban in Kanji and it means something like signboard or billboard. It can also mean the shingle hanging outside of a shop to indicate whether the shop is open or closed. That's a very traditional use of the word when it's written in Chinese characters in Kanji and when it's used in the context of a signal card system, it tends to be written in the Japanese alphabet here, a gana. So we're using it in that context, the signal card system because that's the way that Toyota uses it. The visualization thing is somewhat of a coincidence, but within the agile community it became for whatever reason. I think one or two people who had access to very high SEO websites wrote about the visual boards and in one particular case, a Japanese gentleman who wasn't very familiar with Toyota, at least not at that point in time, when he helped me using the word Kanban. He used it in the way that an ordinary Japanese person might interpret it, meaning a billboard or a signboard or something like that. In his mind he saw the Kanji written version of it rather than the Hiragana version. So for me, kanban is about cool systems and signal cards, inventory control. It's not so much about visualization, although really what happened is that both of these things became a core part of the method. And the visualization is important and it's been a fundamental piece of my work since before the agile management book.

David Anderson: 7:15

If you're going to manage professional services, work in tangible goods industries, you need to make the intangible goods tangible. You need to make the invisible work visible. You need to visualize the work in its workflow. So that was very important the idea that if you can't see it, you can't apply all sorts of common sense to the situation.

David Anderson: 7:44

And I would see managers who often wouldn't have very sophisticated university training in the physical industries and they would use their common sense and they'd make very good managerial decisions. But in the IT world, professional services everyone's got a university degree. Most of them have two or three university degrees and yet they make very good managerial decisions. So they could go for a cup of coffee in the break time and the manager running the Starbucks, who may not have a university degree, is a better manager than they are. And fundamentally, that problem needs to be fixed in the 21st century. And if you're going to start to fix it, you need to make the invisible work visible. And it's purely a coincidence that there is a Japanese world kanban written in kanji characters, and it happens to imply that concept.

Richard de Kock: 8:51

And then, coming back to your original point, you were saying that during the writing of your 2010 book on Kanban, you wanted to focus more on that evolutionary change component. We're trying to find out the reasoning for the you bringing in the service paradigm and that customer experience paradigm, so to speak, and you were.

David Anderson: 9:12

I hope I didn't break that train of thought yet, but oh, the Kanban book was introduced with that evolutionary change thing, but I very quickly realized that we'd lost sight of something fundamental from the very first implementation that we had done we myself and a manager at Microsoft called Dragos Demetrio in their Microsoft's IT department we had lost sight of the fact that our original motivation was improved service delivery.

David Anderson: 9:44

And by 2012, I really needed to communicate the business benefit. If you adopt Kanban, it's not just about evolutionary change and eliminating the human resistance you might get to changes in your organization. There is an actual, tangible business benefit, which is improved service delivery. So that hadn't gone away. I was I'd simply de-emphasized communicating it. And I recognized in 2012 that I needed to change the focus and start to emphasize that a lot more. Around that time 2012, 13, 14, that's when people started sticking their hand up in classes or workshops and saying excuse me, but when is a change and improvement? How would you know? And that led to the fit for purpose concept the focus on not just service delivery, but the focus on fulfilling customer expectations and therefore becoming a customer experience thing.

Richard de Kock: 10:53

I don't have to say your work on just around the service element and the customer experience side is being nothing short of brilliant. This is me coming from a service background. I appreciate that when I read that. If you read that and you apply those publications outside of the Can Bear maturity model, they're seriously impressive pieces of work. The fact that you provided a full journey approach on how organizations should compete through that customer experience and how values should be delivered through service all in an evolutionary context with CanBan at the heart of that Genuinely I thought that was a masterpiece.

Richard de Kock: 11:31

So whoever hasn't read Fit for Purpose or hasn't been able to see how that's all interweaved into your new publication, I'd highly recommend that, along with the session you did, chinary Change Explain I'll pay a team conference. I saw that years ago, david and I was blown away by how you created those parallels between Bruce Lee and the work around that. Absolutely brilliant, but to the point. And the question that I wanted to ask was you have managed to beautifully synthesize and craft three really complex bodies of work together management and process, agility, service value delivery and customer experience. And yet there are very few organizations who have successfully got a handle on even one of these, never mind all of them. Each topic takes a significant mind ship within organizations and requires significant organizational change and learning to sort of get your head wrapped around them, never mind execute on them successfully. So how do organizations practically approach this? It's a minefield. It's really heavy, complex topics. How would you recommend that an organization starts to tackle all of these to be successful at all three?

David Anderson: 12:49

So, yes, and you're right that we've learned the hard way that what seems like fairly obvious common sense, like focus on your customers understand why they want to do business with you, satisfy their needs, etc. Etc. It's actually quite shocking and overwhelming for people. So, in recognition of that and in recognition of the inertia that exists in organizations, some of which is very cultural, whether it's the company culture or the country culture that they live in, they've grown up in, it's a significant challenge and that's really at the root of the maturity model. So, while the book's called Kanban Maturity Model, it's really the organizational and leadership maturity model and it's Kanban patterns patterns of Kanban implementation mapped to different levels of organizational maturity and quite a lot of detail on organizational culture. What's the level of trust, what's the level of innovation, what's the social cohesion like and so forth. So this very multi-dimensional understanding of leadership capability and organizational culture and the organizational maturity, its level of resilience, its ability to manage risks and so forth. And then, given all of that, how do you implement Kanban at that level? And while most executives I speak to will ask what do you want? What would good look like? The description of their ambition would map to level four or five rarely six, but usually four or five on the maturity model. But they're running a level one organization and the key is to understand that. You don't walk into a level one organization with a level four solution and somehow flip a switch. The real skill is to understand that in a level one organization you want to take them to 1.1 and then 1.2 and after some period of time you get to level two and then you might think about how do we get to level three? So the maturity model lays out a roadmap for that and this is through 10 to 15 years of experience, helps you to figure out where the leverage points are and what things you can do now and what things will have to wait to wait or wait until you have that better level of maturity, that higher resilience, better risk management, improved leadership and so forth. So at a very simple level, it tends to focus on let's just demonstrate that we know how to get something done.

David Anderson: 16:13

My last real job back in 2006 and 2007 before I started the company. When I first got there they hadn't deployed any new software in production for months and my boss had said can you get that fixed? So I spoke with people on my team and they said well, we have this. They called it the rapid response team that was supposed to do small, incremental changes on our IT systems. We have this process and it's broken. I said, okay, we need to fix it. Well, some weeks went by and nothing got done, and I will spare you the detail. But eventually I reached a point where I said pick a single ticket from the tracking system and Give it to some people and have them Analyze it, design it, build it, test it, deploy it in production just one, and when you can show me you can do one, then we'll talk about two.

David Anderson: 17:16

And once you can do two, we might talk about scheduling a release that involves more than two things. But until you can do one, get from zero to one. Then show me you can get from one to two and then we'll talk about, let's call it, advanced processes. Now you're quite a profound point that what I'm describing. There is a transition from maturity level, one to two, really, or even the zero one and two.

David Anderson: 17:44

And once we, once we get on our, you know the concept that we can map a workflow and track, instrument the process, track it.

David Anderson: 17:53

We know what we're doing, that there's a Consistent way of doing things and when somebody new comes in, we teach them this is how we do things around here.

David Anderson: 18:04

Well, once we've got to that level, then we can start worrying about are we any good at it?

David Anderson: 18:12

So we've got consistent process, but we don't have consistent outcomes. We're not trustworthy from the customer's perspective. And then we can start to focus on improving the consistency of the outcome, which leads to a focus on you know, stop starting and start finishing, identify blockers, put in place issue management and resolution, escalation procedures and so forth, in order to Remove delay, focus on Swarming on things or improved collaboration, anything that keeps things moving. So so, once we know what we do and we can do it consistently, the next thing is to focus on flow, and our ambition there is to make the flow trustworthy, because we need to build trust with our customers and other stakeholders and gradually, other, more sophisticated concepts Become possible. Now, often I go to conferences and I hear some talking heads who's got some agenda and they'll say something like you know, it's not important to do things right. It's much more important to do the right thing, and being able to prioritize things properly by business value is much more important than improving your processes.

Richard de Kock: 19:40

No, it isn't it's nonsense.

David Anderson: 19:43

Imagine that you've got a completely ineffective process. It's often broken, it doesn't happen. It's often broken, it doesn't flow properly, it's entirely unpredictable and untrustworthy. But you've got God's gift to product management as your uber prioritizing product owner, who has infallible capability of prioritizing things correctly by business value. So they funnel things into you one, two, three, four, by the highest most important thing first, second, one and so on, and it's it's perfect, it's infallible. But you've got a piece of shit process and number one goes in and gets stuck somewhere. Number two goes in, it gets a bit further than it gets stuck. Number three goes in four, five. The first one that pops out is number thirteen, and then we get number seven. Eventually number two showed up. Where the hell is number one on? It still stuck somewhere.

David Anderson: 20:48

You actually have to be good at what you do before you focus on on. Are you doing the right thing? And for anyone who doesn't believe me, think about a gymnast or a nice skater who has to perform at the highest level. We need to put together their program, their floor program or their skating program. They have to choose the music and figure out all the moves they're going to make and they're going to be scored on those moves, but they can't even think about that orchestration and the program they're going to give in the wherever three or four minutes they have available. None of that is possible unless they know how to land the moves in the first place. For internet energy, you need the capability, right. You need the capability before you worry about you need the how before you worry about the what.

David Anderson: 21:46

So the maturity model builds all of these things in an incremental fashion and if someone's using it as a roadmap and following it, they ought to be able to go step by step in a sensible way that will lead to some predictable outcome, and it's not a case of being the smartest guy in the room that the business owner described a level four business outcome beautifully risk hedged and profitable and happy customers and all stakeholders are happy. It sounds wonderful and we know what that looks like. We can walk in with that organizational design pattern and say, well, this will produce that outcome, but your organization has no chance of getting there. Instead, we need to start where you are and work incrementally, and we need some patience. Everybody needs to be patient, but gradually things snowball, they get faster and you will actually get there faster. By going slower at the beginning, by building it incrementally, you try to make the big leap.

David Anderson: 23:05

That is, there's a very high probability that's going to fail. I don't want to say it's doomed, because there will be outliers out there. There will be some people listening to this who have said, well, I've done that, but it's an outlier. Most people are going to fail if they overreach and it's much better to work incrementally and I look at that work now and Theodora was even my clothe and we've talked about this. The Kanban maturity model, second edition, is the book we wish we had 20 years earlier. If someone else had written that book and we were sitting by in my case Sprint or Muteirola and I had read that book, I would have been much more successful. So I don't care that if someone else had written it, it would have made such a difference in my life back then. So that's, I think, fundamentally why we're really proud of this work because we see a younger version of ourselves and think how valuable would this have been to us if we hadn't had to take 20 years to learn that.

Richard de Kock: 24:20

I can certainly say, from at least my perspective, for whatever it's worth, I've just been. I mean, I got the book I think it was on Monday last week, Monday this week and I've, you know, I battled to get our questions together because I thought, oh, there's just so many things I want to ask and so many things I want to dig into. I'm surprised it wasn't sopping weight with all the value and dripping with the good content that's in there. I really, David, congratulations to you and your entire team who've been involved in this, because it is really brilliant, brilliant work. I'm very excited to start the journey a little bit more on my side as well. But on that point I mean, if I'm a manager, if I'm not even a major, maybe I'm a team lead or someone below that.

Richard de Kock: 25:03

You know, I've been on a personal level trying to get cam band right from a principal perspective anyway, to improve the way I work and so forth, and I've battled. I believe in it fullheartedly. It makes sense. I just can't seem to crack it. How would someone who's still not getting this discipline right try and get an entire organization and I, of course we do this in pockets, I'd imagine, but how would you convince others that they should be taking your approach seriously and investing the time and the effort to start looking at how they transform what they do and read your book, especially those who are now fed up of hearing about agile and don't want to hear the word in their organization again because they just haven't seen the success it claims to be providing. What's your response to that?

David Anderson: 25:52

First of all, I think it is a very real thing, and even 10, 15 years ago, I was meeting companies where they'd say you know, we've banned the word agile, we've had some bad experiences and yet. And then there are other companies that there's one big American bank I can think of that are currently on their fifth agile transition. Yes, folks, the previous four all failed. They keep sticking their fingers in the electric socket, hoping for a different outcome. So yes, that's a real thing. Now I talked earlier about evolutionary change and how it works, with stressors and feedback mechanisms and leadership, and fundamentally, you need the culture in place to be successful and therefore you need leadership to create the culture. You need leadership to drive the change and therefore the high leverage question is where do you get the leadership from? And I blogged about this not so terribly long ago that people have to be held accountable. And I also learned because I live in Spain now most of the people in my office are Spanish, but the word accountable in English doesn't translate into Spanish or Portuguese or many other languages, because responsible and accountable are the same word in Spanish. So I had to think about what's the difference. So responsibility is responsible for doing something responsible for an activity. Accountability is responsibility for an outcome, and if you're going to achieve these things that you were describing, you're looking for an alternative path to agility, because you've been trying this agile thing, perhaps at scale, perhaps at a smaller scale, but for many times. There needs to be accountability. People need to be held accountable and if it's even at a personal level, you need to hold yourself accountable.

David Anderson: 28:05

And then the other word you used, richard, is absolutely correct there has to be discipline.

David Anderson: 28:12

If you decide that the whip limit should be five, there needs to be discipline to stick to that whip limit or any other policy that you could in place any other constraint that you've created as a stressor. Constraints are deliberately stressing, and just this week I was actually writing a mapping of Jeff Bezos's 14 points for leadership at Amazon, with my own work and with the Kanban maturity model, and he talks about this idea of putting in place constraints because it drives innovation, and that's absolutely right. And if your constraints are artificial, if they're virtual, if you like, if you've just decided the whip limit should be a certain number, there's nothing physical constraining that. It's not a physical environment, it's just a policy decision. You need to have the discipline to keep it. So leaders must be held accountable and the organization must be disciplined. That the individuals must have discipline, teams must have discipline, leaders that are put in place should be adhered to. And those two things leadership, accountability and discipline those will take you a long way.

Richard de Kock: 29:37

Through all of your experience today, what has been the most important lesson you've learned and what is the most important lesson you want listeners out there to hear, to help them get more clarity on how they can establish an evolutionary DNA? And you're not allowed to say read your book.

David Anderson: 29:57

I think that technologies change but the human condition endures. And this is actually something that they teach military officers when they're officer cadets, officer training school that yes, the technologies change the military cases, that's weapons that are changing right, and it changes battlefield tactics and so forth, but lessons can still be learned from history because the human condition endures. Therefore, in that sense, humans don't change very much, and certainly not in our own lifetime. So the way humans react to change, the way they react to social circumstances and conditions and culture, leadership, actions and so on and so on, that doesn't change. And therefore we can learn a tremendous amount from history. And we can learn a tremendous amount from studying the human condition, the sociology, the social psychology, the psychology, the neuroscience of humans. And you'll know from a flick through the book that you've had for a week or so already that there's an entire section in there on the human condition.

David Anderson: 31:19

Absolutely, and I think that for me is the big takeaway. And it's about 20 years ago now that a boss I had sent me and some of my colleagues on Marine Corps officer training for a better part of a week and we had some retired Lieutenant Colonel and Colonel from the first Gulf War in 1991 drilling us. It was a very interesting experience. They call it a staff ride, where you relive American Civil War battles and you get to play out the role of one of the officers in the battle, and we did a couple of those. We slept out in tents and Arkansas and the key takeaway for me from that was that technologies change but the human condition is injurious and therefore how we act as leaders requires us to empathize with the human beings that are aroused, the ones that report to us, the customers that we serve, and so forth.

Richard de Kock: 32:33

Thank you very much, david. And just for the list is out there. Not only is the book great to buy and read, but you've also got this amazing online version of it where you've got interactable illustrations and so forth that help you navigate the book as well, for an extremely affordable, I might add, sort of price. So definitely check that out. I'll put the link in the transcript so you could go and look at that. And that brings us to the end of our two part series with David J Anderson. We're really lucky to have had him on the show and thank him tremendously for coming on and letting us interview him, and I hope that you enjoyed it as much as I did and that it provided you with as much clarity as it provided for me. Don't miss out on our upcoming episodes with pioneer of jobs to be done theory and inventor of outcome driven innovation, tony Elwick. Those are also going to be extremely insightful. But until we meet again, take care and be safe.