#97 - Personal Kanban & Collaboration Equation - Jim Benson

 

 

“A highly functional team defines the right environment and has what they need to be the best professionals they can be. And that always includes agency and psychological safety."

Jim Benson is the co-author of “Personal Kanban” and is currently working on his upcoming book “The Collaboration Equation”. In this episode, we started by discussing Personal Kanban, how it differs from a to-do list, and its two main rules, i.e. visualizing our work and limiting our work-in-progress. Jim also shared practical tips on managing our personal backlog, doing prioritization, and limiting our work in progress. In the latter half of our conversation, we discussed Jim’s new book, “The Collaboration Equation”, starting with the discussion about the common collaboration challenges and why professionalism and psychological safety are prerequisites to building high-performing teams. Jim also explained the concept of collaborative leadership and gave practical tips on how we can measure effective collaboration.  

Listen out for:

  • Career Journey - [00:06:42]
  • Current State of Productivity - [00:08:17]
  • Obeya - [00:10:12]
  • Rules of Personal Kanban - [00:12:44]
  • Kanban vs Todo List - [00:14:46]
  • Managing Backlog - [00:17:07]
  • How to Do Prioritization - [00:20:23]
  • Limiting Work in Progress - [00:24:26]
  • Collaboration Equation - [00:27:36]
  • Collaboration Challenges - [00:29:07]
  • Professionalism - [00:31:06]
  • Psychological Safety - [00:33:21]
  • Collaborative Leadership - [00:36:39]
  • Collaborative Process - [00:41:04]
  • Measuring Collaboration - [00:46:09]
  • 3 Tech Lead Wisdom - [00:51:09]

_____

Jim Benson’s Bio
Jim Benson is the CEO of Modus Cooperandi, and co-founder of Modus Institute. A pioneer in applying Lean and Kanban methodologies to knowledge work, Jim is the creator of Personal Kanban and Lean Coffee, and co-author of Personal Kanban: Mapping Work | Navigating Life, winner of the prestigious Shingo Research and Publication Award. Jim is a sought-after keynote speaker and humane management thought leader who coaches and supports companies and knowledge workers at organizations around the globe. His other books include Why Plans Fail, Why Limit WIP, and Beyond Agile. His upcoming book The Collaboration Equation will be out in Summer 2022.

Follow Jim:

Mentions & Links:

 

Our Sponsor - DevTernity 2022
DevTernity 2022 (devternity.com) is the top international software development conference with an emphasis on coding, architecture, and tech leadership skills. The lineup is truly stellar and features many legends of software development like Robert "Uncle Bob" Martin, Kent Beck, Scott Hanselman, Venkat Subramaniam, Kevlin Henney, Allen Holub, Sandro Mancuso, and many others!
The conference takes place online, and we have the 10% discount code for you: AWSM_TLJ.
Our Sponsor - Skills Matter
Today’s episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals.
Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones.
Head on over to skillsmatter.com to become part of the tech community that matters most to you - it’s free to join and easy to keep up with the latest tech trends.
Our Sponsor - Tech Lead Journal Shop
Are you looking for a new cool swag?
Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available.
Check out all the cool swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags.

 

Like this episode?
Subscribe and leave us a rating & review on your favorite podcast app or feedback page.
Follow @techleadjournal on LinkedIn, Twitter, and Instagram.
Pledge your support by becoming a patron.

 

Quotes

Career Journey

  • For me, it’s always been about bringing groups of people together, whether it’s in a band or whether you’re building a subway or making software or whatever, but bringing individuals together with their individual perspectives and ideas, and putting them into a group and then building something awesome from it.

Current State of Productivity

  • When Tonianne and I wrote “Personal Kanban” in like 2009, 2010, and then released it right at the beginning of 2011, we were reacting to the fact that everyone we were talking to was telling us that they were overloaded. I have too much work.

  • What we realized was the one thing digital age gave us was a lot of opportunities to do a lot of things at the same time. That hasn’t gone away. With COVID, in fact, it’s become a little bit worse. Because we have a limitless number of things to do. And a lot of people are really tired of doing them sitting in their house. They want to get out, start working with other people again.

  • There’s another idea in Lean called an Obeya, which is basically a room where you would have your Kanban and then all the other visualizations that you would use to manage your work because Kanbans aren’t enough. They’re really important, but you need more visualizations than that.

  • Because so many people have gotten stuck in JIRA or they get stuck in Trello or something, and it’s not all the information they need, and they start to get lost.

Obeya

  • They’re usually physical. The Obeya is literally a room where any professional working on the team can go and become informed about what they’re doing and what everybody else is doing. Everything that’s going on. So every experiment. Every piece of work. Everything that’s been completed. Every issue that’s growing up. Every frustration that people might be having with the customer or other teams or what have you. All of that is in that one spot. So when a professional goes into that room, they know how to help.

  • I hear people already going, “You know, I think my Kanban’s enough”. It’s not enough. And so every time you have a question that you’re repeatedly asking somebody else, that’s probably an indication that should be a visualization somewhere. That should be on the wall.

Rules of Personal Kanban

  • The two rules for personal Kanban are:

    1. Visualize your work, because you can better manage what you can see. So, if you can’t see it, it’s really hard to keep track of it.

    2. Limit your work in progress. So we tend to start lots of things and not finish them. And what happens when we do that is we don’t stop thinking about it. It’s in our brains. It’s using up our mental capacity, our cognitive capacity. It’s decreasing the amount of capacity that we can use to focus on other things.

      • There are a lot of variables that we remember we don’t think about because they just seem normal to us. But if you start loading on 5 or 6 or 10 things, you become very weighed down by that.

      • We want to limit your work in progress, the things that you’re doing right now to one, two or three things. And then that way, you can focus on them and finish them with quality, and then move on to the next thing.

Kanban vs Todo List

  • The format of the personal Kanban is that you have stuff you haven’t done yet, stuff you’re doing, and stuff that you’ve completed. That sounds obvious. But no other system actually has that.

  • If you have a to-do list, what happens is you write down this bunch of stuff that you might do. And then when you’re done with it, you like violently cross it out. And then if you do that, you don’t remember you did it.

  • That thing about remembering, thinking about all the work that we have on our plate, that’s called the Zeigarnik effect. There are two parts of the Zeigarnik effect. Once we start something, we don’t stop thinking about it. But the other part of it is when we finish something, we get closure, we move on and we forget we did it.

  • The Kanban provides you with a clear list of things that are coming up. It helps you focus on the things you’re doing now, but it also provides you with a clear list of things you already did. And then you can go back and look at that and say, “Did I like doing these things? Was the experience good? Was this horrible? Did this happen on time? Did it not happen on time?”

  • Unless we actually go back and interrogate the work that we did, we’re never gonna plan effectively for work in the future.

Managing Backlog

  • Work is very individual.

  • Scrum is not a universal way to develop software. The work is unique and work is unique from day to day and minute to minute. There’s stuff in our work that we know is going to happen. And in Lean, we call that standard work. And then there’s stuff that’s weird. David Snowden might call that complexity or something very complicated. We need to understand that those two things are real.

  • We want to set up a Kanban or personal Kanban or our backlog to reflect that some of the things in that backlog we absolutely know are going to go perfectly fine. When you are looking at your backlog, people tend to look at it like I’ve got a bunch of tasks.

  • What we knew then was as professionals, there was stuff in there that freaked them right out. And you couldn’t schedule that work like you schedule anything else. And what was even funnier was, initially, they had used story points to estimate them, and there was no correlation.

  • So ask yourself when you’re setting out your backlog, what is it that’s about to happen to me? If there’s a lot of unknowns in that, A, give yourself more time. B, find someone at least to pair with, if not to mob with. Understand that the more those things become complex or the more those things become difficult, the more they need to be collaborative.

  • The biggest failure I see is people will pull over three incredibly difficult things to do at once, and then they’ll drown.

How to Do Prioritization

  • I will tell you right now that no one in the world has a problem with prioritization. Having a problem with prioritization is like having a problem with bleeding. So the bleeding isn’t the problem. The wound or the reason you got the wound or the internal hemorrhage, that might be the problem.

  • When we want to prioritize our work, we need to look at our work in context. The easy prioritization that we do is we will do P1, P2, P3 backlog, and we will WIP limit those columns.

  • And then when you’re pulling your work, you can pull from any column you want, but it’s just a way to organize your mind around what you think at the time is going to be a priority. We’ll also set up, again, those quadrants, the kitten, the crocodile zombie quadrant. That is prioritization. It’s just prioritization based on complexity or fear. You can do effort and impact. You can do importance and urgency.

  • So that is prioritization. What does your work need you to do? And how can you see it?

Limiting Work in Progress

  • I’ve seen people like start doing personal Kanban, and then they lose control of their WIP, then they’re like, “Oh, I lose.” And then they leave. They never come back and do it again. This isn’t a professional sport, and it isn’t an elimination tournament. You can kind of stop and then come back again. It’s okay. It’s human to do that. You didn’t fail.

  • Part of the reason for building the Kanban is so that we’re aware that we are breaking our WIP limit and then we’re going to do whatever we can to get back to it. That’s the most important thing for me. It’s not you absolutely have to stick to three things.

  • There are a lot of tips about how to not let other people come in and screw you up.

    • The first would be to let your teammates know that you are doing this.

    • The second thing is to find ways, always, to work with other people.

      • The weirdest thing in the world is we will let ourselves be interrupted all the time until we’re working with somebody else. And then it becomes intolerable that we would let anybody interrupt us. And weirdly enough, for them, they’re like, “Oh wait, those two are working together. I better not bug them.”

      • Pairing actually kind of creates this like a little bubble of don’t bug me that really helps you limit your WIP because while you are there working with that other person, it’s unlikely that you’re going to suddenly find yourself surfing Facebook, because you are actively focused on another human being.

Collaboration Equation

  • The equation is individuals in teams create value. So mathematically, individuals plus teams equal value.

  • What I find is that in Agile, we talk a lot about teams. In Lean, we talk a lot about value. No one talks a lot about the individuals. Definitely, no one talks about all three together. But you can’t have a team without people in it. And you can’t have a team without something to do.

  • Every highly functional team that I have is that the team knows they have defined, they have gotten together. They don’t just know, but they’ve gotten together and defined what we call a right environment, which is do the professionals on your team have what they need to get their job done? Do they have what they need to be the best professionals they can be?

  • When they have, that’s always going to include agency. It’s always going to include psychological safety, because those are prerequisites to being professionals in the first place.

  • That is what the book is about, is how do you build a system that allows everybody to be leaders, and doesn’t do that by making the organization flat, but it does that by distinguishing between management and leadership.

  • Leadership is an action. Anyone can be a leader at any time as long as they have agency and they know what to do.

Collaboration Challenges

  • What’s interesting was when everybody was in the office, there were so many cues that somebody else was handling something and they didn’t need to worry about it, that people didn’t pay attention. And what we’ve noticed is when everybody went home and became distributed and they lost that, they started to demand things. Like I would like to be part of the planning process.

  • We found that collaboration started happening more. Because it had to be more intentional. And so people were collaborating like crazy at the office, but they never realized it cause they didn’t have to schedule it.

  • They would process information while they were doing that, and that’s collaboration. Doesn’t have to be, we are going to get together and do this thing. It’s that we understand that we, as a team, process this work and this information together.

Professionalism

  • The company [Turner Construction] was so professional. They didn’t tolerate problems. They didn’t blame and freaked out when a problem came up. They just figured out ways to solve it. We worked together to find better ways to solve the problems.

  • Professionalism to me means that you understand your work, how you can help other people, and you are engaged fully in honing your skills, in learning, in growing, in continuous improvement. When you have a team that does that, that is professionalism. Because you will not hesitate to ask.

  • The term that was used that now is a big part of the book is acting with confidence. “That lets me act with confidence.” They were such powerful words because it became immediately clear that most people can’t act with confidence. And that is bad. That’s a bad thing.

Psychological Safety

  • At Turner, they have something they called the right environment. And when they launched a project, the team gets together and says, “What are the things that we need to do a professional job?”

  • They’re most often things like, we want to be treated with respect. We want to treat other people with respect. We want to have a good onboarding process.

  • They will set up their own set of expectations culturally for how that group is going to operate. When you do that, you will very quickly identify what agency means for this team. And what psychological safety means for this team.

  • At its root, psychological safety is being able to act with confidence. Something’s come up. Something’s triggered action in me and I’m going to make that action, and I’m not afraid of reprisal. I’m not afraid of failure. I’m not afraid of stepping on other people’s toes. And part of that is cause I know where everybody’s toes are.

  • We have the work visualized. We know what everybody else is doing. We know we’re not going to undermine someone else’s work because we already know what we’re doing. So when we don’t visualize our work, when we don’t see what’s going on in our group or in other groups, we can’t act. Because we’re never sure if someone else is already acting.

  • Agency and psychological safety can be thwarted by working with jerks who like to scare you and stuff. But almost every time I come up against issues with them, no, there’s no jerk. It is a jerk free environment. But still, nobody’s acting because they haven’t gotten together and said it’s important for us to act.

  • Agency is just understanding what action is appropriate and having the ability to take that action. And psychological safety is not much different. They’re kind of two sides of the same coin that were invented because they were dealing with two other symptoms that might not have been root causes.

  • The root cause is, do you understand your culture? Have you defined your culture? Do you have an agreement about it? And then have you found a way to visualize and implement it?

Collaborative Leadership

  • What has become screamingly clear to me is that if you have a strong leader, you’re already three quarters of the way to losing. Because if you have one strong leader, it means you have a whole bunch of people without psychological safety.

  • Leadership was not synonymous with positional power. Leadership was taking the lead to cause an action within the organization.

  • The leadership part was fully transferable. The positional power and power distance didn’t change at all. That is collaborative management. That’s collaborative leadership right there. If you can nail that, almost all of those other administrative problems go away.

Collaborative Process

  • The right environment exercise, the first thing is you do a value stream mapping exercise which is straight out of Lean, but we make it for knowledge work. What we do is we get together with the team or the group and we have them create a map of how their workflows from concept to the end.

  • While we’re doing that around that value stream map, we’re mapping what works and what doesn’t work, which is the kind of the traditional Lean stuff. But for us, the big thing is where do you need to collaborate with each other, with other teams, etc.

  • Most teams die on the beachhead of dependencies. Dependencies don’t really exist. You make them up. All a dependency is, is you having a structure in your company that doesn’t match the structure of the work. And the more you try to convince yourself some other team owes you something, the more unlikely it is you’re going to get it.

  • We want to see in there, what is the real collaborative structure of our work? What’s our real social framework? Who do we need to have more touch with? Who do we need to form some working agreements with?

  • And then we move into the next thing, which we call the charter.

  • In the charter, we have a series of four exercises that look at: Who are we as a team? How do we want to work together? What are our boundaries? What are our expectations of each other? What are we supposed to be giving to the customer? And we build out that kind of cultural map.

  • The third thing that follows that up, that is now informed by understanding both the culture and the flow of work, is what information do you actually need to get your job done? What tools are you currently using to hide, kill, wound, maim, or otherwise harm the information that you need?

  • Everyone has a different tar pit for their information, and what they do is they put it in there and then they forget, and then they ask each other. And then every time you ask someone else, it’s an interruption. It slows you down and you get different information than they gave you last time. It’s not necessarily updated or improved.

  • We want to make sure that people have an information infrastructure that supports the culture, and that obviously usually involves an Obeya. And then at the end of all of that, we build kind of a continuous improvement roadmap and we get them to work on a way to manage their work where they make sure that in their flow of work, whether they’re doing Scrum, Kanban, there are always a few improvement tasks in there, and that they’ve made a commitment to doing the improvement work, not just having a retrospective every so often and then forgetting everything they said in the retrospective.

Measuring Collaboration

  • There are a few easy metrics. One is, are things improving? So literally, you can visualize whether or not things are improving very easily because the thing that you are improving improves. So it’s either going to be the team’s happier. You’re getting more done. Your clients are not as angry. Your bosses don’t punch you as much as they used to. Whatever it is, the improvement cycle is helping you do that.

  • Bugs just happen in softwares. No, they don’t. You type them with your fingers. You do this. You are the bug. So if you want to stop being the bug, slow down and do the work. Don’t turn in crap because it’s the end of your sprint.

  • What we did with them was on their Kanban, when they moved stuff into done, there was a section that had a smiley face. There was a section that had a flat face, a frowny face, and an angry face. And if anything was frowny or angry, everyone had to come over and help fix it. Because we know when we check in the code that it sucks. It’s rarely a shock.

3 Tech Lead Wisdom

  1. When you assign work to a person or someone takes work on, they identify with that work, and then they are unlikely to ask for help.

    • If the work doesn’t go well, they’re likely to do wrong things wronger to get it done. So with your team, figure out a way to see complexity. See when those tasks come up.

    • It’s not a failing of the person. There’s something that actually requires more than one human being to work on, more than one perspective.

  2. Right now at the end of COVID, everybody feels very tired to me. People are really raw.

    • Right now, if things are seemingly tense, try to figure out a way to not just make it less tense, but to get people to talk about kind of why, or what’s going on with them. Because a lot of us don’t realize that we’re tense.

    • Your team really needs to have each other’s backs right now. And if they’re not, they’re going to start stabbing each other’s back. So might be a good time to take a couple days out and do a team charter exercise or something else that just kind of gets you all on the same page and lets people bring some of these out. Maybe even just do a Lean Coffee.

  3. Leaders or managers, we frequently don’t realize when we shut people down. So keep an eye out for that.

    • Quite often, when we’re in a role of a manager or called a leader, we try to do all the leadership things. Other people will exhibit leadership and we will politely or otherwise shut them down. Because what they’re talking about doesn’t make sense to us.

    • The challenge there is how can you create space for them to explore what they were thinking about? Because if you shut them down, you might stop them from doing “the stupid thing”. But you will stop them from doing the smart thing in the future. They will develop learned helplessness because of that interaction.

Transcript

[00:01:58] Episode Introduction

Henry Suryawirawan: Hello again, to all of you my listeners. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. And very happy to present today’s episode number 97. Thank you for spending your time listening to this episode. If this is your first time listening to Tech Lead Journal, make sure to subscribe and follow the show on your podcast app and social media on LinkedIn, Twitter, and Instagram. And for those of you who enjoy this podcast, and want to contribute to the creation of the future episodes, support me by subscribing as a patron at techleadjournal.dev/patron.

My guest for today’s episode is Jim Benson. Jim is the co-author of the famous “Personal Kanban” book and the creator of Lean Coffee. He’s also currently working on his upcoming book, “The Collaboration Equation”, which planned to be released in summer 2022. In this episode, we had a discussion around his two books, “Personal Kanban” and “The Collaboration Equation”. We started by discussing Personal Kanban, why we should use it and how it differs from a more common to-do list. And Jim explained in details the Personal Kanban two main rules, which are “visualize our work” and “limit our work in progress”. Jim also shared practical tips on how we can manage our personal backlog, prioritize our work, and importantly limit the amount of our work in progress. In the latter half of the conversation, we discussed Jim’s new book, “The Collaboration Equation”, starting with the discussion about the common collaboration challenges that we all face, and why professionalism and psychological safety are the two prerequisites to building high performing teams. Jim also explained the concept of collaborative leadership and gave practical tips on how we can measure effective collaboration.

I really enjoyed my conversation with Jim, learning about Personal Kanban and the insights on how to improve personal productivity, and the collaboration equation along with the principles on how to foster thriving collaboration within a team or company. If you also find this episode useful, please share it with your friends and colleagues who can also benefit from listening to this episode. Leave a rating and review on your podcast app and share your comments or feedback about this episode on social media. It is my ultimate mission to make this podcast available to more people. And I need your help to support me towards fulfilling my mission. Before we continue to the conversation, let’s hear some words from our sponsor.

[00:05:54] Introduction

Henry Suryawirawan: Hi, everyone. Welcome to Tech Lead Journal podcast. Today I have a guest with me who is one of the pioneers in the Lean and Kanban methodologies, applying it to work and personal life. He is the author of a famous book, “Personal Kanban” which was published in 2011, I believe. He also created the Lean Coffee. If you went into meetups or some other formats that follow this lean coffee, I’m sure you know what I’m talking about. So the book that Jim wrote, “Personal Kanban” actually won a very prestigious award called Shingo award. And he is writing another book which is up and coming in this year called “Collaboration Equation”. So my guest is Jim Benson. So Jim, welcome to the show, really looking forward to have this conversation with you to talk about personal Kanban and collaboration equation.

Jim Benson: Thank you, Henry. Me too.

[00:06:42] Career Journey

Henry Suryawirawan: So, Jim, I always like to start my conversation by asking my guests to introduce themselves, telling about highlights or turning points in their career.

Jim Benson: Ah, turning points. Oh, there’s so many. One’s career is usually pretty much being pushed into kind of a rubber room and pushed, I mean, like being shot out of a gun and everything’s a turning point. But I started off being an angry punk rocker and musician in the late seventies and early eighties. I’ve had a wonderful accidental career in music. Did some music for television, some music for films, had some dance hits in India. Crazy stuff.

While I was doing that, I realized that it probably wasn’t gonna be a good long-term career. So I became a civil engineer. One often built subways and freeways and big things like that. And while I was doing that, we had large teams of people like hundreds and hundreds of people building like a subway system. And this was either before or just at the beginning of the internet. So we were able to handle huge distributed teams at scale, building something in a coordinated way without any of the tools that we have now. So for me, it’s always been about bringing groups of people together, whether it’s in a band or whether you’re building a subway or making software or whatever, but bringing individuals together with their individual perspectives and ideas, and putting them into a group and then building something awesome from it. That’s actually, oddly enough, not only a turning point for me, like figuring out how to do that, but it’s also the topic of the new book.

[00:08:17] Current State of Productivity

Henry Suryawirawan: So before we went into the new book, “Collaboration Equation”, I know that you wrote this book a long time back, “Personal Kanban”, almost 11 years ago now. So yeah, you wrote this book a long time back, so maybe if we can just dive a little bit to that book. What do you see now in the current productivity world? Or maybe is it already solved? The kind of personal productivity and life kind of a question?

Jim Benson: So when Tonianne and I wrote “Personal Kanban” in like 2009, 2010, and then released it right at the beginning of 2011, we were reacting to the fact that everyone we were talking to was telling us that they were overloaded. I have too much work. I have this too much of this. I have too much of that. And what we realized was the one thing digital age gave us was a lot of opportunities to do a lot of things at the same time. That hasn’t gone away. And with COVID, in fact, it’s become a little bit worse. Because we have a limitless number of things to do. And a lot of people are really tired of doing them sitting in their house. They want to get out, start working with other people again.

So what we’re looking at now is there’s another idea in Lean called an Obeya, which is basically a room where you would have your Kanban and then all the other visualizations that you would use to manage your work because Kanbans aren’t enough. They’re really important, but you need more visualizations than that. Tony and I have been working a lot recently with getting our clients set up with their teams to have a single place where all their information is. Because so many people have gotten stuck in JIRA or they get stuck in Trello or something, and it’s not all the information they need, and they start to get lost. So that’s been the big turning point. That’s been the big kind of lesson learned out of COVID is that.

[00:10:12] Obeya

Henry Suryawirawan: Obeya, this is a new term for me. So maybe if you can explain a little bit. Are you advocating people to get into a physical room or a digital room? Or how does it work, actually?

Jim Benson: Yes. Well, they’re usually physical. So before COVID, I had the good fortune to work on a bunch of billion dollar plus construction projects in New York city. For every construction project, you initially have the initial project office, and then that moves into a construction trailer as the project’s being built. And there’s so many different things going on all the time that everyone becomes lost. Most of their work ends up being just coordinating with each other to try and keep track of that work. So we started building physical rooms on the job site with all that information in it. So the Obeya is literally a room where any professional working on the team can go and become informed about what they’re doing and what everybody else is doing. Everything that’s going on. So every experiment. Every piece of work. Everything that’s been completed. Every issue that’s growing up. Every frustration that people might be having with the customer or other teams or what have you. All of that is in that one spot. So when a professional goes into that room, they know how to help.

During COVID, Tony and I started using a product out of France called iObeya, which allows us to build something like that online. It’s iObeya.com. If you just go take a look. So we started initially putting Obeyas into Miro, which was awesome. But Miro tends to become very messy very quickly. So the clutter started to make it difficult or even impossible to figure out what was going on. iObeya divides different things into what they call walls, which are certain sections with headings. For our headings, it’s modus daily operations, creative production, PR, et cetera. And so in each of those, we have maybe five or six different visualizations for the things that are going on at a time. And that’s for a company that only has four people in it.

So I hear people already going, “You know, I think my Kanban’s enough”. It’s not enough. And so every time you have a question that you’re repeatedly asking somebody else, that’s probably an indication that should be a visualization somewhere. That should be on the wall. So yes, it’s awesome if we’re all co-located, but if it’s virtual, they’ll work there too.

Henry Suryawirawan: Really awesome concept. So I’ll make sure to put it in the show notes for people who are interested to find out more about this Obeya.

[00:12:44] Rules of Personal Kanban

Henry Suryawirawan: So you mentioned that Kanban, of course, is still a must, right? So you wrote this book, Personal Kanban. You have two rules about personal Kanban. Maybe you can brief us for people who also would like to figure out how best they should spend their work or their life, or maybe reduce the number of things that they need to do. Because I, personally, in this digital modern life, have so many things to do. So many opportunities to learn, but also at the same time, so many things that I wish I want to do. Tell us more about these two rules of personal Kanban.

Jim Benson: So the two rules for personal Kanban are visualize your work, because you can better manage what you can see. So, if you can’t see it, it’s really hard to keep track of it. It’s just kind of that simple. And the second rule is to limit your work in progress. So we tend to start lots of things and not finish them. So we’ll start 5, 6, 12 things at a time, and they’re all in flight in one way or another. And what happens when we do that is we don’t stop thinking about it. It’s in our brains. It’s using up our mental capacity, our cognitive capacity. It’s decreasing the amount of capacity that we can use to focus on other things.

So if you take just one thing, you’re remembering who it’s for, when it’s due, what you’ve done so far, who you’re working on it with, what you’ve used, what you’ve learned, how you’ve deviated from your original plans, when it’s due, how angry people are gonna get, when you’re not done with it. The list just goes on and on. One day I tried to list everything that you had to think to remember about a task, and I ran out of paper. It just went on and on and on. So finally I just put, you know, dot dot dot. So there are a lot of variables that we remember that we don’t think about because they just seem normal to us. But if you start loading on 5 or 6 or 10 things, you become very weighed down by that. So we want to limit your work in progress, the things that you’re doing right now to one, two or three things. And then that way, you can focus on them and finish them with quality, and then move on to the next thing.

[00:14:46] Kanban vs Todo List

Henry Suryawirawan: So I’m sure many people would have seen Kanban, maybe like what you mentioned, in JIRA or in Miro or some other tools.

Jim Benson: Those tools, they took our ideas and did a very sloppy job of implementing them. Yes.

Henry Suryawirawan: But normally they would see it in their work. So I rarely see people who have this personal Kanban. Mostly what people do is to-do list. So why do we need to build personal Kanban for ourselves versus just doing it in to-do list?

Jim Benson: So just really quickly, the format of the personal Kanban is that you have stuff you haven’t done yet, stuff you’re doing and stuff that you’ve completed. That sounds obvious. It sounds like, well, of course you would. But no other system actually has that. So if you have a to-do list, what happens is you write down this bunch of stuff that you might do. And then when you’re done with it, you like violently cross it out. Ah, you kill it dead. And then if you do that, you don’t remember you did it.

So that thing about remembering, thinking about all the work that we have on our plate, that’s called the Zeigarnik effect. And there are two parts of the Zeigarnik effect. Once we start something, we don’t stop thinking about it. But the other part of it is when we finish something, we get closure, we move on and we forget we did it. So the Kanban, it provides you with a clear list of things that are coming up. It helps you focus on the things you’re doing now, but it also provides you with a clear list of things you already did. And then you can go back and look at that and say, did I like doing these things? Was the experience good? Was this horrible? Did this happen on time? Did it not happen on time? I mean, Agile teams are famous for not doing this. They set up a set of story points for something they’re about to work on. They work on it and then they’re like, yeah, I’m done. But they don’t go back and say, was that 13 really a 13? Or was that 3 really a 3? Making story points entirely meaningless and velocity even more meaningless. So unless we actually go back and interrogate the work that we did, we’re never gonna plan effectively for work in the future.

Henry Suryawirawan: So I can see also this retrospective reflection part. Not just doing for the sake of doing, checking things off from the to-do list. But there’s also the reflection part. Did you enjoy the card that you just did? Not just for work, but also for your personal life.

[00:17:07] Managing Backlog

Henry Suryawirawan: But you mentioned in the beginning that we are drowned by this so many opportunities and to-do things that we want to do. I’m sure like for myself, I have things to read, things to watch, things to learn about. So how do we manage all this? Do we need to keep our backlog as well? How do you advise us here?

Jim Benson: So work is very individual, which is why if someone comes and tells you like, we’ve developed one way to develop software. David Allen will tell you he’s developed one way, a universal tool to manage your personal work. In fact, it says that in the beginning of “Getting Things Done”, I have developed the universal way. No, you haven’t. And just like you know, Scrum is not a universal way to develop software. The work is unique and work is unique from day to day and minute to minute. There’s stuff in our work that we know is going to happen. And in Lean, we call that standard work. And then there’s stuff that’s weird. David Snowden might call that complexity or something very complicated. We need to understand that those two things are real.

So we want to set up a Kanban or personal Kanban or our backlog to reflect that some of the things in that backlog we absolutely know are going to go perfectly fine. On any given day, I know the blog post that I’m going to write, I’m going to be able to write it and post it and everything is going to be fine. When I’m launching a new advertising campaign, there’s a lot of that, that I have no idea what’s going to happen. So when you are looking at your backlog, people tend to look at it like I’ve got a bunch of tasks.

So what we did at Spotify at one point when we realized that this was becoming a problem was we took the column for their backlog in their Kanban, and we divided up into four sections. One section was kitten. The next section was crocodile. The next section after that was zombie, and the fourth one was zombie crocodile. And then we said, okay, based on how much this ticket scares you, put it in the backlog. And there was a bunch of kittens and there were some crocodiles and there were some zombies and there were some zombie crocodiles. So what we knew then was as professionals, there was stuff in there that freaked them right out. And you couldn’t schedule that work like you schedule anything else. And what was even funnier was, initially, they had used story points to estimate them, and there was no correlation.

There were things that were thirteens that were in the easy. There were things in the kitten, and there were things in the zombie crocodile that were like twos or threes. So ask yourself when you’re setting out your backlog, what is it that’s about to happen to me? If there’s a lot of unknowns in that, A, give yourself more time. B, find someone at least to pair with, if not to mob with. Understand that the more those things become complex or the more those things become difficult, the more they need to be collaborative. That’s a pretty big pro tip for the PK 101, I know. But the biggest failure I see is people will pull over three incredibly difficult things to do at once, and then they’ll drown. They’ll just drown.

[00:20:23] How to Do Prioritization

Henry Suryawirawan: I can understand that, yeah, we should understand about complexity and maybe, this is standard work or maybe repetitive work. Just like publishing blog posts, publishing podcasts, those kinds of like repetitive tasks. But in the first place, if there are so many things, how can we prioritize? I’m sure like we should not just put everything in the backlog, put it in the standard and scary, complex stuff. But how should we prioritize?

Jim Benson: We’ve gotten many con calls over the years saying we have a problem with prioritization. Could you please come in and help us? So I will tell you right now that no one in the world has a problem with prioritization. Having a problem with prioritization is like having a problem with bleeding. So the bleeding isn’t the problem. The wound or the reason you got the wound or the internal hemorrhage, that might be the problem.

When we want to prioritize our work, we need to look at our work in context. The easy prioritization that we do is we will do P1 P2 P3 backlog, and we will WIP limit those columns. So you can only have three or four things in P1, five or six in P2, and then an infinite number of things in P3. And then when you’re pulling your work, you can pull from any column you want, but it’s just a way to organize your mind around what you think at the time is going to be a priority. We’ll also set up, again, those quadrants, the kitten, the crocodile zombie quadrant. That is prioritization. It’s just prioritization based on complexity or fear. You can do effort and impact. You can do importance and urgency.

But we’ve set up maybe 40 or 50 different ways for people to prioritize their backlog based on what the situation is. And one of my favorites, I think, which kind of helps break us away from worrying about the backlog in the Kanban, is we were working with a team, with a company, actually, that was drowning in technical debt. They couldn’t figure out what to do next because everybody was fighting about things. And, of course, the CEO and the leadership were all saying, you can only do new features. And they’re like, we’re building all these new features on quicksand, on very thin stilts on quicksand, in a heavy wind and something bad’s about to happen.

So what we did with this group was we took a table in their conference room, and we had them print out all of their bugs, every single one of their bugs. And when they came in, one of the rules was you couldn’t call it technical debt anymore. We had to call them defects. Because technical debt is a really vague term. Defects are much more of a punch in the face. And so then on the table, the first thing was we set one side of the table was this will kill the company. The other side of the table was this has no impact on the company. And then we laid out all of those defects in there and they filled up the table. There’s 250 of them. Then we said, okay, for the width of the table, one side is this will take forever. And the other is we can do this in five minutes. And then they laid that as well. And then what happened was the defects started to find clusters of corporate pain and simplicity of fixing. And then we were able to take little clusters out and say, we’re going to work on this cluster for this sprint. We’re going to work on this cluster for this sprint. We didn’t take the ones that were super awful at the end of the table, but first we just did it so that people could learn how to fix things. So that is prioritization. What does your work need you to do? And how can you see it? I love doing that stuff.

Henry Suryawirawan: Yeah. Sounds very insightful for people who are drowned in so many things. Maybe you should try like the first rule in the personal Kanban. Visualize your work. If you don’t visualize the things that you are going to do, sometimes it’s hard. You just think, oh, I have so many things, a bunch of stuffs and they’re all important. But actually, maybe if you visualize it, you get clarity on what to do next.

[00:24:26] Limiting Work in Progress

Henry Suryawirawan: The second rule, limit work in progress. I know in Lean, this is always emphasized. But for personal life, again, sometimes is not that straightforward. What kind of gist that you can tell us as individual how to limit work in progress? And why we should limit work in progress?

Jim Benson: So I also wrote a book called “Why Limit WIP?” And that book’s out too, if people want to buy that. Limiting work in progress is difficult, and it’s difficult for me. So I wrote the books and won the awards and did all these things. It’s hard. What’s easy is to be working along and then suddenly realize, “Oh no, I’m doing way too many things.” First thing, I just want to say that because I’ve seen people like start doing personal Kanban, and then they lose control of their WIP, then they’re like, oh, I lose. And then they leave. They never come back and do it again. This isn’t professional sport, and it isn’t an elimination tournament. You can kind of stop and then come back again. It’s okay. It’s human to do that. You didn’t fail. But part of the reason for building the Kanban is so that we’re aware that we are breaking our WIP limit and then we’re going to do whatever we can to get back to it. That’s the most important thing for me. It’s not you absolutely have to stick to three things. It’s that once you start doing two or three things, you’re going to quickly find out. Wow, I get a lot done every day if I do that, and I’m proud of the work. So it’s not just productivity. It’s effectiveness. I feel like a better professional because I am a better professional. I’m getting the right work done at the right time, in the right way.

So there are a lot of tips about how to not let other people come in and screw you up. The first would be to let your teammates know that you are doing this. Maybe invite them with them and say, look, my goal is to get control of my work and finish it quickly. So I’m going to do a couple things. One is I’m going to be available to all of you people from 9:00 AM to 11:00 AM every day. But from one to three, I’m going to focus. And that doesn’t mean you can’t contact me, but it’s going to mean don’t contact me for something stupid. Contact me if you really, really need me.

The second thing is find ways, always, to work with other people. The weirdest thing in the world is we will let ourselves be interrupted all the time until we’re working with somebody else. And then it becomes intolerable that we would let anybody interrupt us. And weirdly enough, for them, they’re like, oh wait, those two are working together. I better not bug them. It’s awesome. So pairing actually kind of creates this like little bubble of don’t bug me that really helps you limit your WIP because while you are there working with that other person, it’s unlikely that you’re going to suddenly find yourself surfing Facebook because you are actively focused on another human being.

Henry Suryawirawan: Well, I wasn’t aware about this pairing or collaborating with people can actually limit the distraction, limit the work in progress and all that. But now that you said it, I think, yeah, that kind of makes sense.

Jim Benson: It rocks for that.

[00:27:36] Collaboration Equation

Henry Suryawirawan: So let’s go to the next book that you are writing now. Thanks for sharing about personal Kanban. So it’s called “Collaboration Equation”. First of all, is there any equation behind it?

Jim Benson: Yes. The equation is individuals in teams create value. So mathematically, individuals plus teams equal value. What I find is that in Agile, we talk a lot about teams. In Lean, we talk a lot about value. No one talks a lot about the individuals. Definitely, no one talks about all three together. But you can’t have a team without people in it. And you can’t have a team without something to do.

What I’ve noticed about every highly functional team that I have is that the team knows they have defined, they’ve gotten together. They don’t just know, but they’ve gotten together and defined what we call a right environment, which is do the professionals on your team have what they need to get their job done? Do they have what they need to be the best professionals they can be? And when they have that, that’s always going to include agency. It’s always going to include psychological safety, because those are prerequisites to being professionals in the first place. So that is what the book is about is how do you build a system that allows everybody to be leaders, and doesn’t do that by making the organization flat, but it does that by distinguishing between management and leadership. We think that leadership is an action. Anyone can be a leader at any time, as long as they have agency and they know what to do.

[00:29:07] Collaboration Challenges

Henry Suryawirawan: So we have gone into this pandemic and we are just getting back to normal in some parts of the world. Collaboration, I’m sure, was disrupted during that pandemic time. People can only do over webcam, web calls, and all that. What kind of problems that you see? Maybe you have seen it in the last few consulting work. What kind of collaboration problems that currently people are facing?

Jim Benson: Well, so what’s interesting was when everybody was in the office, there were so many cues that somebody else was handling something and they didn’t need to worry about it, that people didn’t pay attention. And what we’ve noticed is when everybody went home and became distributed and they lost that, they started to demand things. Like I would like to be part of the planning process. Almost all the software development teams that we’re working with, in all of the fields that we’re working with right now, these individual contributors who previously were like, just tell me what to do, now they’re like, just let me help you plan next of the work that I’m doing.

We found that collaboration started happening more. Because it had to be more intentional. And so people were collaborating like crazy at the office, but they never realized it cause they didn’t have to schedule it. They could just turn around and say, “Hey,” and someone would say “What?” and then you’d say, “This” and then there’d be this exchange, and they wouldn’t realize it. They would process information while they were doing that, and that’s collaboration. Doesn’t have to be, we are going to get together and do this thing. It’s that we understand that we, as a team, process this work and this information together. That’s been the most fun thing for us to see is that previously extremely complacent software crafts people have started to become software professionals and working together to actually improve. Whereas before, they were just trying to type as fast as they could.

[00:31:06] Professionalism

Henry Suryawirawan: So you mentioned a couple of keywords that I could capture just now when you described about the collaboration equation. You mentioned about professionalism. You mentioned about agency, psychological safety. Tell us more why all these are very important in your collaboration equation?

Jim Benson: When I started working with the construction company in New York, with Turner Construction, the original draft of the collaboration equation was almost done. And this was five years ago or six years ago. And I got there. I realized, “Oh my God, I can’t finish this book.” I have to watch these people. And the reason was because the company was so professional. That didn’t mean always wear a suit, and it didn’t mean highly rigorous chain of command and things like that. It meant that they didn’t tolerate problems. They didn’t blame and freaked out when a problem came up. They just figured out ways to solve it. We worked together to find better ways to solve the problems. But they were already way farther than all of the software teams I’ve ever worked with. So professionalism to me means that you understand your work, how you can help other people, and you are engaged fully in honing your skills, in learning, in growing, in continuous improvement. When you have a team that does that, that is professionalism. Because you will not hesitate to ask.

The term that was used that now is big part of the book is acting with confidence. So one of the guys there, Kevin Chase, when he was showing his Obeya to some other people in the company, to the HR people at Turner, they said, “What does this give you? What does this room with all this information give you?” And he says, “When I do something, I know that my boss’s boss, my boss’s boss, my boss’s boss’s boss. They all know exactly what I’m doing. They know when something is stuck and they know when they need to help, and they know why it’s stuck.” He said, “That lets me act with confidence.” And when he said that, it just punched me in the face. They were such powerful words, because it became immediately clear that most people can’t act with confidence. And that is bad. That’s a bad thing.

[00:33:21] Psychological Safety

Henry Suryawirawan: Seems like the confidence thing also relates to the psychological safety, right? Sometimes the environment is not conducive enough for people to act in confidence. Maybe they don’t have information. Yes. That’s one thing. But also at the same time, they are afraid, maybe, to act confidently. So can you tell us more about this psychological safety in collaboration equation?

Jim Benson: So, at Turner they have something they called the right environment. And when they launched a project, the team gets together and says, “What are the things that we need to do a professional job?” When they do that, those things are going to be like we want to be able to eat lunch. One project was like, we want a dog. They can be silly things, but they’re most often things like, we want to be treated with respect. We want to treat other people with respect. We want to have a good onboarding process and blah, blah, blah, blah, blah. They will set up their own set of expectations culturally for how that group is going to operate. When you do that, you will very quickly identify what does agency mean for this team? And what does psychological safety mean for this team?

At its root, psychological safety is being able to act with confidence. Something’s come up. Something’s triggered action in me and I’m going to make that action, and I’m not afraid of reprisal. I’m not afraid of failure. I’m not afraid of stepping on other people’s toes. And part of that is cause I know where everybody’s toes are. So we have the work visualized. We know what everybody else is doing. We know we’re not going to undermine someone else’s work because we already know what we’re doing. So when we don’t visualize our work, when we don’t see what’s going on in our group or in other groups, we can’t act. Because we’re never sure if someone else is already acting.

So agency and psychological safety can be thwarted by working with jerks who like scare you and stuff. But almost every time I come up against issues with them, no, there’s no jerk. It is a jerk free environment. But still, nobody’s acting because they haven’t gotten together and said it’s important to us to act. So agency is just understanding what action is appropriate and having the ability to take that action. And psychological safety is not much different. They’re kind of two sides of the same coin that were invented because they were dealing with two other symptoms that might not have been root causes. So the root cause is, do you understand your culture? Have you defined your culture? Do you have an agreement about it? And then have you found a way to visualize it and implement it? So when the Agile manifesto says individuals interactions over processes and tools, it’s just wrong. Cause individuals cannot interact without processes and tools. So yeah, I believe in breathing over blood pumping. It’s like, no, no, no, you don’t. You do not. You do not believe in that. Obviously, I have a lot of psychological safety.

[00:36:39] Collaborative Leadership

Henry Suryawirawan: So yeah, you mentioned about this culture very important. Yes. I can see good culture breeds good collaboration. What about the responsibility of a leader here? Maybe if you can touch on, is it part of your equation? What kind of traits that leaders should have in this collaboration equation?

Jim Benson: So the first thing is I would invite us to call the managers. What has become screamingly clear to me is that if you have a strong leader, you’re already three quarters of the way to losing. Because if you have one strong leader, it means you have a whole bunch of people without psychological safety. I can’t put it anymore bluntly than that. So I don’t mean no management. I don’t mean no reporting structures. I don’t mean that there isn’t an organization. I’m not going the Holacracy route. But what I am saying is that for me, the word leadership can be exemplified in this story, and the story is in the book.

So there were two young women. There are levels at Turner, and the entry level is a level one. There were two entry level, level one engineers named Amanda and Savannah who worked in the estimation group, architectural estimation. They decided that they wanted to build an Obeya for their team, almost all of whom outranked them. So they went into this room and they built this Obeya, and they immediately had to socialize that the boards that were in there, the Kanbans and the other boards that were in there. They exhibited leadership by doing that. And in this case, leadership was not synonymous with positional power. Leadership was taking the lead to cause an action within the organization. They were very successful at doing this. The team ended up adopting it. And then when Amanda and Savannah got promotions and moved to other groups, the boards stayed there and they stayed there all the way through COVID and everything.

On the flip side of this, there was an upper manager who was a Vice President named Charlie Whitney. Charlie had a problem on one of his projects that was going to repeat itself all the way up this 40 story building. So the problem was noted on the sixth floor. They were working their way up the building and it was going to become a very expensive multimillion dollar problem by the top of the floor. So he took this young guy named Randy Castillo, and he said, “Randy, I’m going to introduce you to this problem-solving format.” And he says, “I want you to go to the Gemba. I want you to go to the construction site and I want you to watch as the trades people are installing this stuff. And I want you to work with them. I want you to collaborate with them to solve this problem.” So just to put this in perspective, Randy, at the time, was a level one. Charlie is a Senior Vice President. Charlie is literally his boss’s boss' boss’s boss’s boss. So there’s a ton of power distance. And the first time we went in and talked to Randy, Randy looked scared to death. It was like the President of the United States shows up and says, “Could you do this for me?” And you’re like, “Holy crap, it’s the President!” And so, in just a few months, Randy and the trades were able to beautifully solve these problems collaboratively. Charlie showed up once every week or so, and just kind of coached him and guided him on what he was doing. But as it went on, the leadership there transferred from Charlie Whitney to Randy. And by the end, Randy was the leader. He was showing leadership in all sorts of ways.

I love that example because the leadership part was fully transferable. The positional power and power distance didn’t change at all. That is collaborative management. That’s collaborative leadership right there. There’s a million little questions about like, how do you do annual reviews and things like that. But that’s the biggest part for me is if you can nail that, almost all of those other administrative problems go away.

Henry Suryawirawan: Yeah. You mentioned about strong leaders is part of the big problems. I can see it now, actually. Yeah. Sometimes we admire strong leaders. We want to follow them and we get inspired. But yeah, at the same time, I think what you said about psychological safety, that means people probably don’t speak up so much. Sometimes they’re intimidated by the charm or the direction of the leaders. So I think that’s a very good point that I learned from just now what your description is.

[00:41:04] Collaborative Process

Henry Suryawirawan: So I’m sure in all this equation, there’s also the portion of Kanban or Lean, or maybe some kind of process. So tell us more what process?

Jim Benson: So individuals and teams create value. There is a chapter entirely about kind of personal process. There’s a chapter in there about how to define a right environment and the process in doing that. There’s a chapter in there about collaboratively working together, creating different types of working sessions and workshops and meetings that get results. Because you enter with another person, you develop some sort of system to get you from not having a result to getting the result. And then the last part of that is actually leadership section where there’s all of these different formats for how to promote leadership in people throughout the organization.

To pick one, I’ll pick the right environment exercise, cause it’s one that we’ve done easily 30 or 40 times during COVID and it’s a week-long event. We’ve been very busy during COVID. So out of COVID, about 40 of those weeks, I think, we were involved in what we called right environment exercises, and they are a five-day exercise. You get together during those days and you come up with a few major deliverables. The first thing is you do a value stream mapping exercise which is straight out of Lean, but we make it for knowledge work. What we do is we get together with the team or the group and we have them create a map of how their workflows from concept to the end. People always put like release at the end of their thing. We work for over the course of a week, and by then there, they realize, “Oh, I guess our work isn’t done when we release it, is it?” It’s still a big shock in 2022. That’s the case.

While we’re doing that around that value stream map, we’re mapping what works and what doesn’t work, which is the kind of the traditional Lean stuff. But for us, the big thing is where do you need to collaborate with each other, with other teams, et cetera, and so forth? Because most teams die on the beachhead of dependencies. Dependencies don’t really exist. You make them up. All a dependency is, is you having a structure in your company that doesn’t match the structure of the work. And the more you try and convince yourself some other team owes you something, the more unlikely it is you’re going to get it. And you know that because that’s how you feel about other people. So we want to see in there, what is the real collaborative structure of our work? What’s our real social framework? Who do we need to have more touch with? Who do we need to form some working agreements with? So that we can loan them some people. Sometimes they can loan us some people. We can pair on things, whatever. So anyway, that’s the first part of it. And that’s usually the first time anybody ever has a glimpse into what their work actually is. It can be a very emotional process for a lot of people. Seriously, we’ve had people cry, often.

So in the end, we end up with a really good understanding of what we’re doing. And then we move into the next thing, which we call the charter. In the charter, we have a series of four exercises that look at: Who are we as a team? How do we want to work together? What are our boundaries? What are our expectations of each other? What are we supposed to be giving to the customer? And we build out that kind of cultural map. And while we’re doing that, tons of action items come out of that. Tons of we should do this. We should do that. We should start doing this right now. So it can be just a decision or it can be a change. And we’ll be tracking all these throughout the days.

So the third thing that follows that up, that is now informed by understanding both the culture and the flow of work, is what information do you actually need to get your job done? What tools are you currently using to hide, kill, wound, maim, or otherwise harm the information that you need? So, like people think that Slack is a good way to exchange information. Everyone has a different tar pit for their information, and what they do is they put it in there and then they forget, and then they ask each other. And then every time you ask someone else, it’s an interruption. It slows you down and you get different information than they gave you last time. It’s not necessarily updated or improved. Cause if you ask them four times, like the fifth time, they’re just gonna say, “Dude!” They’re going to yell out like five words that used to be 10 sentences, just to get you off their back.

So we want to make sure that people have an information infrastructure that supports the culture, and that obviously usually involves an Obeya. And then at the end of all of that, we build kind of a continuous improvement roadmap and we get them to work on a way to manage their work where they make sure that in their flow of work, whether they’re doing Scrum, Kanban, there’s always a few improvement tasks in there, and that they’ve made a commitment to doing the improvement work, not just having a retrospective every so often and then forgetting everything they said in the retrospective.

[00:46:09] Measuring Collaboration

Henry Suryawirawan: Thanks for sharing these activities, exercises. Right now, I can see it like the whole end-to-end. So you mentioned about improvement. This is something that probably tickles my mind. Is there such thing to measure collaboration, some kind of metrics? Because in Lean, Scrum, Agile, whatever, you, we have so many metrics. What about measuring collaboration?

Jim Benson: So, there are a few easy metrics. And people who like metrics don’t like these. One is, this is a tough one, are things improving? So literally, you can visualize whether or not things are improving very easily because the thing that you are improving improves. So it’s either going to be the team’s happier. You’re getting more done. Your clients are not as angry. Your bosses don’t punch you as much as they used to. Whatever it is, the improvement cycle is helping you do that. Now, if you are doing an A3, which is a one page Lean tool to help you solve problems, there’s a section at the end of that A3 that basically has you record your results. And if you get used to working in that mindset, the funny thing that happens is people bounce off into two caps. One is the, oh my God, I’ve gotta measure everything super statistically. And the second is I need to understand what just happened and become comfortable with the fact that some of the data that you’re going to get back is anecdotal. It can be a narrative. It can be a feeling.

So we worked with a team once that had a big problem with technical debt in Scotland. They had set up this beautiful bug tracking system with five different layers of importance that’s very specific way to write down your bugs and blah, blah, blah, blah. And they showed it to me. They were so excited. And I said something really mean to them. They said, “What do you think of this?” And I said, “It seems like you just created a huge amount of overhead to track your overhead.” And they’re like, “Well, what should we do instead?” I was like, “Don’t type bugs.” And they’re like, but bugs just happen in softwares. No, they don’t. I’ve owned software companies. I know they don’t. You type them with your fingers. You do this. You are the bug. So if you want to stop being the bug, slow down and do the work. Don’t turn in crap because it’s the end of your sprint.

So what we did with them was on their Kanban, when they moved stuff into done, there was a section that had a smiley face. There was a section that had a flat face, a frowny face, and an angry face. And if anything was frowny or angry, everyone had to come over and help fix it. Because we know when we check in the code that it sucks. It’s rarely a shock. Sure. Sometimes it’s a shock, but rarely. It’s rarely a shock. So if you set up those systems, we didn’t need anything. Number of bugs, there’s your metric, and it’s a totally collaborative metric, cause there’s a collaborative process that built it.

But what I don’t want to see ever, and I will personally fly and rant and scream if you do this, anybody who’s listening – don’t do it on purpose just to make me fly and visit you – I’ve seen stupid measures like numbers of hours spent pairing. It’s like bug fix awards. Don’t do that. Don’t think you have to measure this in some pseudoscientific way. Do it in a real scientific way. Like a psychologist would do it, and actually measure how people feel. A really long answer to that.

Henry Suryawirawan: It’s a very interesting story, actually. I was laughing as and when you describe. So many problems that I could see also in software teams in my career. And also sometimes, you mentioned people know that they committed crap work. Maybe that also goes back to the psychological safety, right? Why in the first place you committed a crap work? Maybe you didn’t want to say that. Okay. I had a problem or maybe this problem is just too complex or maybe the requirement is not good. Whatever that is. Something like acting in confidence, psychological safety, again, is something that is very important.

So, this book sounds really exciting. When is it going to be published? Maybe share us more about it.

Jim Benson: It should be the middle of August. This is the final stretch here, and there’re tons of work happening all at the same time, and it’s very overwhelming to watch, but we now have the cover. The final reviewers are looking at the text. The layout guys doing the layout. There’s an ISBN number for it. It feels real. It finally feels real. I’m so anxious to tell the stories in this book. And as you might guess from this call, I do most of the teaching in this by telling a story and then talking about the implications of that story.

Henry Suryawirawan: I personally enjoyed “Personal Kanban”. Reading it, understanding and yeah, you have some stories there. So looking forward for this next book.

[00:51:09] 3 Tech Lead Wisdom

Henry Suryawirawan: So thanks so much, Jim, for sharing all these insights about personal Kanban and collaboration equation. I have one last question that I normally ask all my guests, which is to share about three technical leadership wisdom. So think of it like advice or something that you want to tell listeners here, maybe from your experience or maybe from your expertise. Could you tell us your three technical leadership wisdom, Jim?

Jim Benson: The first bit of wisdom is that when you assign work to a person or someone takes work on, they identify with that work, and then they are unlikely to ask for help. And if the work doesn’t go well, they’re likely to do wrong things wronger to get it done. So with your team, figure out a way to see complexity. See when those tasks come up. It’s not a failing of the person. There’s something that actually requires more than one human being to work on. More than one perspective. So that’s thing one.

Thing two is that, this one won’t age well, I don’t think, but right now at the end of COVID, everybody feels very tired to me. People are really raw. Right now, if things are seeming tense, try and figure out a way to not just make it less tense, but to get people to talk about kind of why, or what’s going on with them. Because a lot of us don’t realize that we’re tense. And the way I kind of realized this was that I didn’t realize that I was tense. Other people did. And then I started to look around. I was like, “Whoa, Hey.” Yeah. So this is kind of becoming a ball of weird at the moment. And so, your team really needs to have each other’s backs right now. And if they’re not, they’re going to start stabbing each other’s back. So might be a good time to take a couple days out and do a team charter exercise or something else that just kind of gets you all on the same page and lets people bring some of these out. Maybe even just do a Lean Coffee.

And then the third thing goes back to the leadership stuff that I was talking about. Quite often, when we’re in a role of a manager or called a leader, we try and do all the leadership things. Other people will exhibit leadership and we will politely or otherwise shut them down. Because what they’re talking about doesn’t make sense to us. The challenge there is how can you create space for them to explore what they were thinking about? Because if you shut them down, you might stop them from doing “the stupid thing”. But you will stop them from doing the smart thing in the future. They will develop learned helplessness because of that interaction. If they come to you two or three times, and only one of those things works, they’re going to be 66% less likely to bring you the next thing. And so “leaders” or managers, we frequently don’t realize when we shut people down. So keep an eye out for that. Those are my three things.

Henry Suryawirawan: That’s really powerful. The last one I, myself, in my day job, sometimes I do realize doing that. So thanks for reminding all the leaders and managers here. Maybe be conscious about that pattern, right? So sometimes, yeah, maybe the idea is not good at this point in time. But in the future, they might not say smart things as well. Thanks for reminding us about that.

So, Jim, if people want to follow you or maybe ask you to fly to them, where can they reach you online?

Jim Benson: Okay. So, the easy ones are I am @OurFounder on the Twitter machine. And then the second is that if you come to ModusCooperandi.com or ModusInstitute.com, which I’m sure Henry will put in the writeup for that, cause both of them are totally unspellable. Or if you just search Jim Benson Personal Kanban, if you come to any of my websites, there’s a live chat feature there. There’s probably a 30% chance that you’ll get me. There’s a 30% chance that you’ll get Tonianne and there’s a 40% chance that you’ll get Dave. So there’re your odds. But if you get a hold of any of us and you want to talk to me, they will alert me. So I’m very reachable.

Henry Suryawirawan: Thanks for sharing all that. It’s nice to have a live chat to someone that maybe you want to reach out. Thanks for sharing those and I’ll make sure to put them in the show notes.

Jim, it’s been a fun conversation. Thank you so much for sharing all those things and the stories. I really, really enjoyed it. So thanks so much for being in the show.

Jim Benson: Thanks Henry.

– End –