Jim Benson Interview Transcript (WHY LIMIT WIP)
|
Interview Transcript - Jim Benson November 2014 David : Hi. This is David Prior for Projects for Work, and I’m very excited to have Jim Benson back for another interview and you’ve been on the road for quite a while. Isn’t it right? Jim: It is where I live. David: So thank you for taking some time out for this. So we’re going to talk about a couple of things today with the first is about the newer of your books Why Limit WIP. Jim: Okay. David: Right. Can you – I guess before we get in that, for folks who may not be familiar with the work that you in it and the Modus Cooperandi, can you explain a little bit about your work and the main focus of your work? Jim: Sure. So at Modus Cooperandi we help people and organizations actually understand the work they’re doing so they can manage it better. We do this primarily through visualizing work and making sure that people are working at a level that is not just as a sustainable pace as agile we’d say but that they’re working actually within their capacity. So how to measure that capacity, how to understand it, how to figure what impacts that capacity, so if you want to raise it, you actually have to do something to raise it and then how to build cultures of continuous curiosity and improvements. So cultures that noticed when things are wrong or things could be improved and actually set out to change improve them in a systemic and humanistic way. David: Cool. And if people look up Personal Kanban yours is the first name that they’re going to see as well so you’re also pretty famous for that. Jim: Yeah. David: All right. So you got the new book Why Limit WIP and what’s – I’ve got a lot of sort of deeper questions about the book but first, what is WIP? Jim: Okay, so WIP is Work in Process such as what you are doing right now. You as a team, an individual, or an organization. David: And the premise of the book is that we’re all trying to do so too much at once. Jim: Exactly. That we’re all overloaded in some way, and that overload has noticeable, immediate, and deep impacts on quality and the ability to deliver. David: Okay. Jim: And the ability to actually enjoy your work because it – it’s just bad. It feels bad to be overloaded. David: So do you – I would say at a work level and on a personal level, I feel overloaded all the time but I have noticed that to a certain extent, there’s an addiction to the rush of that feeling overloaded. Jim: Yeah. I think that there’s there’s that addiction. There’s also the opposite which is that when we don’t feel overloaded we feel like we’re not doing enough. So we feel guilty when we have any leisure time. So basically if we were – if we were all automobiles, we would feel like we all had to be running at 100 miles an hour all the time in order to be useful. And I’ve pose that that’s not the healthiest way to live. David: So I was – one of the things that I was thinking about when I was reading to that was I’m wondering if it’s sort of an evolution in how we deal with things and use our brains. I mean everybody says you need to be more in the moment, you need to take time out, be reflective and get into things deeper and I can’t remember the last time I sat down and just listen to an album and didn’t do anything else to really get into it. But we’re so focused on this kind of sorting the mail all the time. Jim: Right. David: Maybe – is it possible if we’re just processing everything differently and that this is a permanent thing because of the internet and everything else? Jim: Well, the internet has been a wonderful and terrible thing for human beings. I stop and think about it what it took for my father when he was an entrepreneur and businessman to get something done versus how long it takes me to get the same amount of value created. And because of the internet, because of the immediacy of communication, because of how quickly I can get somebody – a beautiful and complex document describing an idea, I can create value much faster than my father or my grandfather. But my father and my grandfather also used to do things like go fishing. And so there’s a definite trade off in how we’re living because we have so many options and so many opportunities that if we don’t seize them, we feel like we failed. David: Yeah and you mentioned you can create value faster, but we also consume faster. It’s like we’re eating the food without ever tasting it anymore. – Jim : Oh, definitely. David: So we eat more. Jim: Definitely. Yes. And my – commensurate to that, my cost of living right now is ridiculous compared to what my relatives have been throughout their days. David: So we’re burning the machine just that much harder. Jim: Yeah, yeah. Basically we’ve just turned it up to 10 or 11 or – David: Okay, so this leads me my first question about your book. So in the book you talked about, the fact that we’re all kind of at an individual and a company level, everybody is so busy processing that they’re not getting to a deeper understanding of what’s actually happening. And like for me, it was like I work in a mail room. I sort mail but I never take it anywhere. In the book, you’ve got this guy Jason Hold who – the Willy Wonka of mansion, who comes and helps kind of cut through this but just saying, “Stop it. You’re going to do last and you’re going to finish something.” If I’m a mid-senior level manager and I have read your book and it’s like the late brooks of the clouds and just lit me up and I totally get it, how do I deal with this when I go back and then I have to convince senior management? There’s hundred projects left. Screw that. Let’s just do three. Jim: Right, right. And it’s incredibly hard. And so just to back up a little bit, so the book itself is half business novel and half discussion of why limiting work in process is if not a silver bullet, at least a bronze bullet. And being able to have individuals, teams, and organizations be able to better understand what they’re doing, focus on what on what they’re doing, and complete it more quickly and with quality. Because we have so many options right now, we are constantly trying to exercise all of these options simultaneously. And so the corporate level without [inaudible 00:06:34] is way too many projects in a project pipeline. And it’s not – the frustrating thing and the difficult thing is that all of those projects have some value, and that’s why somebody wants to do them. So it’s intolerable to see them there and not be able to act on them. However, what we don’t know is what the capacity is of our software creation machine that we employ. So therefore, since we don’t know its capacity, we just keep dumping more and more and more work into it and then we’re overloading it but we’re not understanding why. And a lot of this is because knowledge work happens in the brain or on a computer, so it’s completely invisible. Bosses and workers have no idea what the impact of taking a new task on is because they view that new task in isolation. Oh, I could do that. But they don’t see that they have a large amount of commitments already that are going to stop them from doing that. And when you tell somebody else who comes to you and says, “I have this really great idea,” and they’re excited and they want to do it you say, “I can’t. I’m too busy.” That makes you a whiner and that’s not politically advisable. So you take on the more work even if you do feel like you have to much work. So when – the problem is, is it – all these options are very exciting. They’re very interesting, and they feel very necessary to somebody who’s growing a company. And if they don’t understand that there really is a capacity issue, they’re going to keep dumping things into the process. The problem is that they’re not going to see that by you telling them that. So you have to be able to show them. You have to be able to create some kind of visual control that shows how work is flowing through your system, the rate which it flows, and the impacts of that rate has on the number of things that you can do at a time. David: So you’re going to have to start doing experimenting and tracking key times and things like that and finding a way to show that to people. Jim: Yes, but the – David: Delays that could cost on projects. Jim: Yes, so you can do cost of delay. You can do through put analysis. You can even show how the current utilization strategy in the organization is leading to higher defects because it’s forcing too many people to do too much work. And you can do that in reports but people have learned to distrust reports in the written word over the years. And so basically what they will do is they will take your report, and they will interpret the report also as a political tool. David: Okay. Jim: And they will interpret it by their own confirmation bias. So they will get the report. They will have an idea what’s really happening, and they will read your report in that filter. But if you can build something like a Kanban, it doesn’t have to be a kanban but it can be something like a Kanban that actually shows over time the impacts of the amount of work coming in and what is it eventually produce whether that’s leading the bottlenecks or work starvation or increased defects or incredible delayed cost or mid-year collisions or integration problems. All of these things are actually visible if you make a system that shows work flowing. And if somebody’s watching that, it’s a lot harder for them to argue with it and it’s more likely to give them an epiphany “Oh, I see this we really can only put so many of these sticky notes through this columns at a time.” David: Right. Jim: And then we see the certain amount, the whole system works out. David: So it’s more like providing them with a way of reporting that doesn’t allow too much room for misinterpretation. Jim: Exactly. David: It’s just a straight up. This is what it is. Jim : Yeah, you want to show them the movie. You don’t want to tell them what you think. David: Yeah, okay. So one of the things that you just brought up was the fact that people are constantly being given more to do, and this is something I’m maybe more looking for advice on because I ran into this in classes all the time and people say, “Well, they just keep adding more and more, and we don’t have a choice. We have to do it.” And I think on the one end, people get – it feels good to be given a lot and told you’re important enough that you have to do this. So people have this – I think it’s like an addiction to it. You want that rush because you feel stressed, but I want to look at these people at a time and just shake them and say, “Stop saying yes to stuff you know you can’t do.” They can tell you to lift a thousand pounds if you know you can’t lift it, it’s irresponsible to say yes. Jim: Right. David: But that’s an empathetic way of responding to a request for now so – Jim: Right. What they don’t know is they know they can’t lift a thousand pounds and they probably know they can’t lift five hundred pounds. But do they know if they can lift a 125 or a 126 or a 137 pounds? David: Right. Jim: So because they – because we don’t know ourselves where the end of our capacity is, we treat our capacity as infinite just as much as anybody else does. And one of the other things is even though those people are complaining about that, let’s say that they’re – each of these people are complaining about [inaudible 00:12:12] and said, “I’m working on five projects right now, and it just feels like too much.” And you take out your project gun and you say, “Which project should I shoot?” They’re going to say, “Oh my God. Don’t shoot my project.” David: Right. Jim: So – because they’ve got – they’ve already sunk part of themselves into that project. And we do like what we do even if we’re overworked. And so once we start to build something, we want to see it get built. And one of the – one project that we had – I talked about this one a lot actually. It was a – everybody in the company was working on literally five projects or more, and they were engaging in third-tier support and they were doing side projects that they weren’t telling anybody else about. So nothing was getting done. And of course, because I wanted them to limit their work in process, I have said, you know what? Why don’t we do where we take each team and make it a discreet unit and each team is just working on one project at a time? We’ll shell the other four, and we’ll get to them after we finish those projects. And two things happened. One is that the management freaked out. They said you can’t script our portfolio like that. And they said, well, nothing is getting done. So would you like to finish something? And then the engineers – the software engineers themselves completely freaked out because they had all these some costs in each of the projects. David: Right. Jim: So I would say finally each team had a Kanban, so is it okay if I – here’s what we’re going to do. Your Kanbans look beautiful, but they’re all lies. And they said, “Yeah, we know they’re all lies. It’s okay.” So underneath your Kanban, I want you to put a piece of paper and then just put post-it notes for what you’re working on your other projects. And so the team started to do that. They had a Kanban, and then underneath they’re starting to put the post-it notes for what they were working on and elsewhere. And it looked like a hula skirt. It was just like wall to wall post. And so it looked so stupid that everybody just stop and said, “Okay. We get it. We have to limit our work in process.” But I tried to tell that to them verbally, and they wouldn’t buy it. But the moment they saw it visually, – David: You showed it to them. Jim: They’re like “Oh crap.” That just looks stupid, and I’m that. David: So I had this thing in classes where somebody mentioned something that I’ve seen happened once where I got an organization to create a Kanban and exactly what you just described happened. They looked at all the amount of stuff they had in-progress and the extra stuff. And this person in my class described the same thing happened to her. That it was so disturbing and overwhelming to look at that the response was “Yeah, we’re not doing Kanban.” Jim: So I love that response, it’s the ostrich with the head in the sand. David: Don’t look down, it won’t [inaudible 00:15:26] Jim: The ostrich looks up, there’s a dog coming. He puts his head back in the sand. So I’m – this is one of the – this is the classic dieting problem. I’m feeling weak. You should go exercise. Yeah, that’ll be – that’s a good idea. David: Tomorrow. I’ll do it tomorrow. Jim: Do it tomorrow. In my talk in Frankfurt yesterday, a day before yesterday. I had a slide that said that human beings took poison so picture of all of these drugs. And that we drove aggressively, and then we got certified in things. And so we basically, we always engage in behavior that’s bad for us. And so what the barrier that you want to breakthrough is not convincing people that they’re doing too much work or that you’re giving people too much work to do. It’s the – it’s not that painful to get to a better place and one of the problems with people who have been through hard transformations – David: Right. Jim: Transformations to wrap or transformations to scram where you just grab everybody – David: I was about to say transformation to agile, yeah. Jim: Yesterday you were doing something and today you are doing something entirely different. David: Right. Jim: It’s the – the whole point of what we want to do with the Kanban is do exactly what happened to those people. I want you to look at this, and then I want you to say, “Oh my God. That is ugly.” David: Right. Jim: And then you have – David: What am I going to do about it? Jim: Yeah. You have three decisions at that point. You can either run away from it. You can do something from it or to it or you can basically just freak out. And the problem that you mentioned in the beginning which is – that your – the people outside your organization are pushing or your team are pushing work into team. This is one of the problems that we have engendered by having a team focus over the last 20 years. So we’re focused so much on teams that we removed them from the rest of the company. And we’ve allowed organizations to say things like “I don’t get what’s going on in IT.” David: Right. Jim: That should be the thing that’s intolerable to us. So the nice thing about the board is when we put the board up, and we start to actually use it even if it’s painful and ugly we see what’s happening and other people see what’s happening. David: Okay. Jim: And you can make a decision about it, and your decision can be – do scrum forever. Your decision can be go back to waterfall. It can be I would rather build ball bearings. But – or I would rather slowly and methodically and incrementally create a process that actually works for my team, which is opposite of what I would like to say. But one of the things I tell people a lot is we seem to think that business – you know there’s a saying, “It’s just business.” Well, saying “It’s just business” is exactly like saying it’s just marriage, except worst. So if we think – if it’s hard to go home and communicate reliably with one person that we love more than anyone else on earth why do we think we can go to work every day and communicate well with thirty people we barely care about? So we need to understand that working with other people is totally necessary and not easy. And the systems that we build needs to promote communication in the team and outside the team as opposed to hinder it. David: So how do you trigger the – I mean the awareness should be as obviously a positive thing, how can you trigger action? Is there a way to do that? If I work with people and I know that they can see it, this is – we have this giant Hollister, this is really bad. But we have to do it. Jim: Yeah, yeah and so – David: Get them pass that. Jim: Well, so there is one thing – so with that particular group, when you’ve got 15 teams of people all staring at the same problem and then you have crazy person like me standing in front of them saying, “You can fix this, and the fixes are fairly easy.” Conceptually they are difficult because you’re so – you’re in so much pain because over the years things have been so poorly managed. But truthfully, all you guys really have to do is just do a reasonable amount of work at a time and give yourself some breathing room so that you can understand what you’re doing. You can do it better and you can complete it. And then we get back to the original thing that you said which is how do you tell somebody no. David: Right. Jim: You shouldn’t have to tell somebody no, but right now you can’t because you have no tools to tell them no. David: Okay. Jim: What you should tell them is I want to continue working with you, and I love your ideas, and I want to build these things. Now, where in the queue shall we prioritize this? Is it a new feature? Is it a project in itself? Is it just a task that I need to get done or that somebody needs to get done? Is it an emergency? Is it nice to have? Is it a need to have? Let’s actually figure out– let’s do some things that we’ve been afraid to do for several years. Let’s actually prioritize it for real. Let it interrupt us if it’s – if it’s that important. But let’s really treat work with the respect that it deserves while we’re also treating the individuals with the respect that it deserves. So the beginning of the Agile Manifesto, the first word in that caplet of the Agile Manifesto is the word “individuals.” But everything we talked about in Agile is about teams. David: So having respect for – you said having respect for the work and the people and trying to be aware and conscious of choices that you’re making. Jim: Yeah, yeah. And then also having – funny thing happens when you put the board up and you visualize everything is happening – where the works coming from, who’s doing what and when. As a coder, I will notice that something I coded is stuck in testing and I own a little of that. That piece of code is a little piece of me. And before it was just – it would up into some black hole and then after a while someone comes back and say, “I’ve got a problem with your code.” David: Right. Jim: So then you get like my code, you know you must be your testing and I know what I was doing when I was coding it. But if you see it, just go over there in the car and just sit. After a while you’re going to say, “Why is that car just sitting there?” And you go to the testing people and say, “Hey, do you need help in this?” We’re really stuck on this. We want to facilitate ownership of the product from cradle to grave by everyone who’s involved in the product? David: Okay. Jim: And if you don’t have that, then you’ll never have the insights necessary to say no. David: All right. So they have to all work on it together. Jim: Uh-huh. David: Cool. You also talk about utilization, and I’ve been running into more and more. It seems like recently people are focused on utilization and a couple of Agile tools are now saying they can help you kind of level people and make sure they are fully utilized. Jim: Yeah. David: I would argue it’s probably not healthy and I would assume that you would agree that they need some downtime as well but when you talk about Kanban overload, is there a way to measure that and consider it as a factor in utilization? So that I could say well, here’s a project that should take 50% of my available time from an hours’ perspective but mentally, it’s going to take up this much more. Jim: Yes, well that’s definitely part of it. So Tonianne, my co-author, has this story where in Washington, D.C. there was a bunch of historians and they were sitting around reading and historians actually have bosses and their boss walks in. Their boss actually was Newt Gingrich, walked in and looked around and said, “I don’t pay you guys just to sit around and read.” And then we walks out and they’re like, “What do you pay us to do?” Because they were thinking right that’s what – that’s what they do for a living. And so there is that part of it but the other part of it is I have spoken at more conferences than I can count and more time -- or have given a lot of classes and I have never had more than one or two people in audiences of hundreds raise their hands when I’ve asked the question “Who here needs more to do?” So utilization is by no means a problem in suffer development. The problem is that we have no clarity into what’s actually being done, how much effort it actually has to take, and what the work is to actually complete something. So there’s a for years there’s been this one study that we’ve gone back to that says 83% of all features in software are rarely or never used. David: Right. Jim: And so we say well, we should be better at figuring out what that 17% are and that’s absolutely true. But, sometimes or all the time I would actually argue when you’re inventing something new, you need to build several versions of it and try them out to figure out what the right one is. And it doesn’t make those options that you’ve discarded waste, and it doesn’t mean those people are wasting their time or underutilized. It means that discovery in software development is a major part of my development process and it’s not just coding testing integration in earliest. David: Okay. Jim: So utilization is a very tricky subject because we are trying to move. Right now, if you walk up to any team and there was a – imagine on the wall there’s this knob and it says “utilization” and it has no markers. David: Okay. Jim: So just a blank knob on a blank wall. And somebody says, “Go change utilization for the better.” David: They’re going to turn it up every time. Jim: Yeah, you’re going to turn it up or you’re going to turn it down, but either way you don’t even actually know how much you’re turning it up or turning it down because you don’t even know the gauge on which the knob has been set. It’s just a blank knob. So right now, what we’re doing is we are trying to impact a variable because we are frustrated but not because we actually have the information that we need to act. David: Okay. What about the push – I mean even – even in Agile companies like Agile Consulting Companies, there’s a push at people booked at a 100% of the time and they say well, if your whole team is working at over 80% capacity for the entire month or a quarter then you can get a bonus or whatever but that means that those people never have time to get better. Jim: Well, and I would argue actually is what that means is you’ve just created a lot of technical debt. So people don’t – because we don’t understand the work and because we don’t understand the capacity, we also don’t understand the impacts of overloading the system. So we don’t understand at what rate do we start to see dimension returns; where is it that we start to see additional cost of delay; where is it do we start to see additional defects and escaped defects; and how often are things coming or used stories coming back because they’re buggy; how often are we building features that we never needed in the first place; how often are we building features that are built like an engineer. We’ve built them but not like a customer would use. So higher utilization usually means greater number of lines of code written. David: Right. Jim: But greater amount of crop. David: Well, true. Well, so when I gave a personal comment recently and somebody thanked me for having a [inaudible 00:28:43] it’s okay to take naps. And one of the things that – you just got off this big long trip you’ve been flying for a while. And you are going to need – I’m assuming you’re going to need some time to recover. Jim: Yes. David: Where you’re not doing anything or you’re not doing – productively contributing to some output because you need to have time to rebalance from being gone and being on a flight. But people don’t consider that to be valuable time. Jim: Right, right. It’s a – David: How do you deal with that? Jim: Well, so let’s say – let’s say that for a moment that you are a smart phone. And somebody talks to you until you have 1% percent of battery left, and then you say, “Hey, I’m a smart phone and I need to be charged.” And somebody says while you’re being charged, that’s not productive time. David: Right. Jim: And so it’s like, no, I am the most wonderful and most complex machine on the planet. But I’m still – I still need to eat. I still need to sleep, and I still need to go to concerts and to look at sky from time to time. David: Right. Jim: And we need to recognize that the this is the thing is that because our work is knowledge work and it’s highly creative, and we’re using the most resource intensive part of our body because our brain burns a lot of calories. So when we’re thinking, we’re working pretty hard. It’s people say you’re just sitting around all day but you are burning just as much calorie – David: [inaudible 00:30:23] telling me I’m sitting around all day and you just figure out of the wire into my head. Jim: Right. Well, so that’s another part of balance right is the – as organisms, we actually do need to get around, get up and walk around. We need to walk up and down some stairs. We need to eat a certain amount of fruits and vegetables and grains and meats. And if we don’t do these things, then we’re going to create crappier and crappier code. And – David: But we’ll have more of it. Jim: Yeah, [inaudible 00:30:55] that’s why we will have more of it. But the thing is for a brief beautiful period of time there, we didn’t have a lot of bandwidth and phones were pretty stupid. So we were back in – back where – all of a sudden we’ve reverted back into this kind of glorious age that we were at when we had Apple tools and [inaudible 00:31:18], where we had like 16K and you couldn’t do very much. Now, unfortunately, we’re backed-up to where we can bloat our phones and we can bloat the internet just like we bloated desktop applications in the ‘80s and the ‘90s. Success went up a par. But I – so we can’t limit our WIP by – the technology won’t let us limit our WIP that way anymore. David: So we have to become mature about what we’re doing somehow. Jim: We do but mostly what we have to do is realize that our attempt at optimization of utilization is actually a direct de-optimization of the people who are actually doing the work. And you can’t just optimize part of a system. So when you are creating software, you have the human, their body. You have the human, their brain. The human, their psyche and you have their time and their energy and blah, blah, blah, blah, blah. So right now, we’re just optimizing for time that is a highly local optimization of an incredibly brittle system that will not function with that focus – with that optimizational focus. David: Cool. So there’s – I mean I guess people are looking at it from a very simplistic standpoint instead a more healthy holistic way of understanding what actually takes to get viable stuff done. Jim: Exactly. And I mean it’s – because one of the hardest things about this is I – even just with the word holistic is that when you start to take a systems thinking approach to knowledge work and then you start to have to deal with the soft sides of things that people are uncomfortable with – being polite, having empathy. Understanding that if somebody doesn’t go home for five days to visit their daughter, they’re going to become a real pain in the ass. That starts to feel mushy and granolaee and crunchy. And that’s the real danger here is that there’s nothing but hard science behind this but the elucidation of it sounds very haggy. So – David: I think – I think the hard part is it makes total sense but it runs counter to what people have grown up thinking from the idea of everybody works in a factory all day. Jim: Yeah – David: [inaudible 00:33:43] the machine. Jim: And it’s very anti-calvinistic and we still live especially in the US but even in Europe and in some ways, Asia’s even worse. We live in a very Calivinistic society where there is work to be done and you got to get out and do it. And the problem is there used to be work that you had to get out and do because if you didn’t repair that fence, all of the cows would leave. But now it’s you have to get out and do this 45 projects because I thought of them. David: Right. Jim: And it’s like – David: And that makes some valuable because you they were in your thought. Jim: Exactly. And so we have to realize that just as you couldn’t send your son out in 1920 to build 17 fences in one day. You also can’t have somebody go out and write 6,000 lines of code every single day. David: Cool. All right. So the book is called Why Limit WIP. You can get it at Amazon, and if you’re subscribing to that new unlimited Kindle thing, it’s even free. Jim: Yeah, yes it is. David: Cool. So I want to ask you about the school and the new stuff you have gone on because that’s pretty exciting as well. Jim: Oh you bet. So really quickly, we are in the process of preparing for a launch of something called Modus Institute and it’s at modusinstitute.com. At least it’s flash pages now. And we are building an online school that will be teaching next generation project management techniques. We’ve gathered together 30 of the best sought leaders and practitioners and lean software development and modern or I guess whatever we are calling management today. There’s no word for it yet. And this is an online school that has a learning – your own pace model but it also has direct access to instructors and peers. So we not only want to build a school where you go and look at videos, which is what all the other schools have but we also want to build a strong community of practice. So when people learn about Kanban or they take a class and try to get in it and they learn about Monte Carlo simulations or metrics or from Dave Gray learning about the different ways to visualize and brainstorm. That after they learn those techniques and they start to implement them, they can have – you can have conversations with peers and with the instructors. So you’re not just hung out to dry. It’s like a real university online. And our first class is on managing successful distributed teams and that will be ready in the beginning of January. So we’re going to launch in Q1 of 2015, and we’re really looking forward to it. David: Cool. I think it’s great. I mean that people that you’ve got to involved I’m psyched about them. I’m hoping at some point, there’s going to be something metrics-related because you’ve got some of the stuff Troy is doing is really awesome and Dave as well. Jim: Yeah. So Troy and Dave [inaudible 00:37:03]. So that’s one of the things. I mean we just mentioned that there’s the soft side of better management, and there’s also the hard side. There are real metrics and by real, I mean actually real metrics that measure how a team is doing, how an individual is doing, and allows not only them to improve but allows you to make projections and do away with estimates and move right into actual statistical probabilistic forecasting. So it’s a – hopefully the workplace of the future is a place for people actually enjoy going to work and they get a ridiculous amount done because they’re not doing the wrong things. David: Well and with this I think also the people – your people – the people will have access to the instructors one-on-one. Jim: You bet. David: That’s great. All right. So this is going to come out in January. I’ll put up a link to the institute as well. But when this – when it does go out, I would love a chance to talk to you guys about it again. Jim: Oh, absolutely. That would be fun. David: Cool. All right. So thank you very much. I hope you get to recover from the travel a little bit, and I hope everybody’s going to go pick up the Why Limit WIP book and also Why Plans Fail as well. Jim: Indeed. David: Because both were helpful. Cool. All right, Jim, thanks a lot. Really appreciate it. Jim: Thanks, Dave. David: Cool.
|
Here is a complete transcript of my interview with Why Limit WIP - An Interview with Jim Benson (podcast interview with link to transcript)
|
Jim Benson and the folks at Modus Cooperandi have some great stuff going on. I had the chance to interview Jim recently about his new book "Why Limit WIP", some of the new offerings coming from Modus Cooperandi and (of course) Personal Kanban. Follow the links below to check out parts 1-3 of the interview. If you'd like to read a transcript of the interview, you can find it here. |
