Kanban and the Collaboration Equation with Jim Benson

Join hosts Murray Robinson and Shane Gibson in conversation with Jim Benson, renowned author of “Personal Kanban,” as they delve into his new book, “The Collaboration Equation.”

In this episode:

• Jim sheds light on how Kanban can be used to identify and tackle bottlenecks, empowering teams to maintain focus and enhance productivity.

• We explore the phenomenon of information starvation within organizations and how it undermines individual autonomy and decision-making capacity.

• Jim reveals the secret to fostering collaborative systems that provide team members with the information they need, leading to improved decision-making, increased effectiveness, and a more innovative and resilient organization.

Don’t miss this insightful discussion, especially if you’re keen on maximising collaboration and productivity in your team!

Read along you will

Murray: In this episode, we talked to Jim Benson, author of personal Kanban, about his new book, the collaboration equation. Jim describes how Kanban allows teams to focus and see bottlenecks so they can resolve them. He explains how organizations starve people of information, safety and purpose and describes how to build collaborative systems that give people the information they need to make better decisions which will in turn, make their companies much more effective, innovative, and resilient. 

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Jim: And I’m Jim Benson.

Murray: Hi Jim. Thanks for coming on today. We want to talk to you about your new book, the Collaboration Equation. Why don’t you kick us off by telling us a bit about who you are and what’s your background and experience is. 

Jim: Okay. I was an angry punk rocker, on the planes of Nebraska in the middle of America. and. We had to learn to play instruments. We had to learn how to distribute music. We had to learn how to make albums. We had to learn how to get reviewed in France before there was an internet, before there was anything digital. I tried to be a professional, angry punk rocker for a couple of years, and decided that wasn’t a good long-term business proposition for me. So I went to get a degree in urban planning. Built freeways, subways. Giant things with multi-billion dollar price tags around the world. I did that for about 10 years. 

Also while doing that, I was the co-chair of the northwest region of the names Project AIDS Memorial Quilt. So during that time, I was also a fairly involved AIDS activist and counselor for people who were in grief. At the end of all of that my business partner, William Rowden, and I decided that we wanted to start a software company.

So we left our cushy jobs and started Gray Hill Solutions. When we did that, we were like what should we do? How should we build this software? And a friend of ours said, you should talk to my friend Kent. So we went and got a copy of XP explained before it was published, a pre-published version of it, and basically launched one of the first agile companies out there.

We were in business for about a decade during which time we were working with a lot of people including Dave Anderson. And when we accidentally invented Kanban that changed my life. It changed Dave’s life and pretty much everybody else that came into contact with it. Wrote the personal kanban book after starting Modus Co-operandi with Tony Ann Di Maria

And ever since we have been working with agencies and companies, large and small, around the world to make work flow better. I’m a senior faculty member with the Lean Enterprise Institute. I am a faculty member at the Deming Institute, and like I said, I’ve been doing Agile forever.

My goal is nothing less than to help people build their own processes, their own structures, so that they can get the right work done at the right time. Everything I talked about requires collaboration. And so the collaboration equation, the new book encapsulates all the experiences from my 57 years of being a resident of the planet Earth and all the crap that I’ve gone through.

And builds a coherent system where we can actually be agile or we can actually be lean and not just come in and tell people to do some random things and expect that they will magically become either of those two things. That’s me.

Shane: Are you able to give a two minute overview of what Kanban is? 

Jim: Okay? Imagine this, you have a bunch of work and you don’t know what the hell’s going on. You’ve either buried it in some tool or you’ve given it to some product owner or product manager, and you don’t know what’s really coming up. You don’t know what people are actually doing, and you don’t know what you’ve completed. Kanban says, Hey, you should be able to see the work that’s coming up. The work that you’re doing now and the work that you’ve completed. So you write down all of the things that you’re gonna do. You put those into a backlog that’s visible in a column. Then the next column has the stuff you’re doing, which you only wanna do a few things at a time so that you can focus on them and finish them with quality. And then, when you’re done, you pull them over to Done so that you remember what you did. So that when you actually do have your retrospectives, you can actually remember what you did. I cant imagine why anybody would do such crazy things. You can better manage what you can see, and none of what I’ve said precludes two week iterations. One week iterations or anything else. Its simply visualizing your work and limiting your WIP. Nothing more. 

Shane: Do you think there is any Scrum team out there that doesn’t run a Kaban board? 

Jim: Yes, lots of them because they don’t limit their whip. They’re also incredibly lazy about what is complete. So a scrum board is a very lazy way of visualizing the flow of work. And that’s where we ran into problems. That’s why this whole thing came about. One day I asked my team when we were doing XP and they were doing the three mindless questions. What’d you do yesterday? What are you gonna do today? And do you have any blockers? Everybody always tells you that they did stuff, they’re doing stuff, and no, they don’t have any blockers. Shut up and leave me alone. 

And I had the audacity to ask, Hey the thing you said yesterday, did you finish, and then they said, no. I said, why not? And then they had an excuse and they said, how about that thing you were doing the day before? It’s not done, but I’m waiting for this. And it’s, how about the day before?

And so with our team of eight people. I said, let’s just write down everything that we’re doing right now on the whiteboard. And there was just tons of stuff. And psychologically, your brain cannot handle that level of work. So the whole point of all of this wasn’t to invent a new agile. The whole point of this was like, Hey, we’re doing too much stuff. And that, that fundamentally isn’t agile. It’s not a sustainable pace, it’s not respecting our workforce. It’s not what we signed up for. 

So the reason people were starting too much work is because they were overzealous in the sprint planning meeting about what they were selecting. And then they were doing a bunch of stuff. Or they do crazy things like user stories where you write something down that’s vague in a user story and then people pull that in. It launches 200 tasks that no one ever sees because you’re focused on the user story and not on the actual work. So I do have my criticisms of the way agile has been applied, but I’m super agile.

Murray: What happens if you visualize your work, but you don’t limit your WIP? 

Jim: I guess you get messy. Look, the system only has two rules. Visualize your work and limit your work in progress. Visualize your work isn’t a system. Beneficial constraints ensure that you are able to focus on the work and finish it. You don’t fall prey to the zygarnic effect. Which says that every time you start a task, you keep thinking about it until it’s done. Who it’s for, how far along you are, what you’ve learned, how you’re going according to plan, how you’re deviating from that plan, how pissed off people are getting because you don’t have the work done yet. Who’s gonna get more angry about which of the tasks in flight that you have aren’t gonna get completed. All the political stuff. So there’s a ton of state information that we’re shoving in our brains and expecting that, that’s not gonna have any negative repercussions.

If we have 15, 20 things in flight at one time, that’s a hell of a lot of information parsed all the time. So we’re visualizing the work to get that stuff out of our head. We’re limiting the work in progress to stop that number of internal conversations and to stop the number of opportunities for other people to interrupt you.

Every time you start a new task, you’re starting a relationship with the customer and the other people who are involved in that task, which means that each time you pull a new task, each time you start a new task, you are opening yourself up to tons of opportunities for interruptions. Is this done yet? Do you need this? Do you have that? What are we gonna do about this? What do we decide here? So you must limit your whip in order to be doing Kanban but you also must limit your whip in order to be agile.

So the word kanban comes from Toyota and it’s a giant plastic card that travels along with an engine block, and it says, this engine block needs these things. And while they’re building things at Toyota, there’s only a certain number of engine blocks that they’re building at a time. So they’re limiting the work in progress of the assembly line so that they don’t overproduce. In auto industry, a big problem is overproduction. GM is famous for making cars that no one will ever drive. So seeing the work limiting the amount of output was the paradigm that David and I took when starting this whole thing. 

Murray: How does Personal Kanban differ from Team Kanban? 

Jim: There is no difference. The words personal kanban mean work of interest to people as opposed to industrial Kanban. The book Personal Kanban goes back and forth, it has your personal work and your, teamwork. No one works alone so it is really dangerous for us to overly focus on our personal work because then we become our own little bottleneck. We become our own little silo. Everything that we do, we’re collaborating with our team, with managers, with suppliers, with customers. The creation of value is always a collaborative act. The more that we focus on being personally productive the more that we will continue to run into the same ineffective business styles that we have right now. 

So most of the companies that we work with, people spend a lot of their times in meetings talking about things that they’ve already talked about, because they’re really crappy at collaborating. They’re crappy at alignment. They’re crappy at remembering what they do. And it’s because they don’t visualize those things.

The five years before Covid, I spent a lot of time working in New York City with Turner Construction, building skyscrapers, hospitals, universities. Huge projects. When you’re building a building of that size, say it’s a 2.1 billion dollar building, there’s a lot of moving parts and the design is by no means finished when they start the project. The project is constantly being redesigned until the very last day of work. So you can imagine that you’ve got thousands of people working on this building over the course of its lifetime. And if you don’t get it done on the day that it’s contracted to get done you and lots of other people are going to start incurring millions of dollars in penalties. If you have a 70 story building in, Manhattan that’s being built, that means that you have 70 stories worth of tenants who have already signed their leases and are waiting for the building to open and are getting ready to move. So they’re going to be in a world of hurt if your building gets delayed. That building is constantly learning as it’s being built. 

At all of the construction companies at Turner Construction, now we have a thing that’s called an Obeya Room. An Obeya is a room where the professionals working on the project have all the information they need in order to behave professionally. They can make decisions. They can see that things are going wrong, are going right. They can make alterations in schedule, budget. The particulars of what’s being built. And they can do it in a situation where everything is visualized . It’s expected that you will say things like, Hey this isn’t going right. Or there’s a problem. Or I just learned this new thing. And that’s what the collaboration equation is all about. Building that environment, building that room full of visualizations and building that system that particular group of people need in order to do that particular work at that particular time.

Murray: Yeah. So we work in bureaucracies. What is it about that type of organization that makes it difficult for people to collaborate or that destroys confidence or leads to bad decision making?

Jim: It’s a manufacturing paradigm. What you build in, those situations is bottlenecks for decision making and the flow of information. Information does not flow smoothly through the organization. People are not informed, they’re not able to make decisions, let alone empowered. 

One of my favorites systems that I’ve seen was in Louisville, Kentucky at the general Electric Large Appliance Division. The one plant where things were pretty awesome was plant five. So you had an Obeya room there. They called it the blue room. And in that blue room, they had all of the sales information, all of the shipping information all of the quality, all of the defects. What part of the country was having different problems. Every day while I was there, line workers who assembled the fridges would go into the blue room and they would check out the stuff. No one told them to. They just did because it was interesting. And they had the best internal culture because they felt not only respected by having that level of information, but they would also able to act on it. I heard them talking about it on their breaks. 

Murray: When I think about bureaucracy, it’s a hierarchical structure with a lot of layers. It’s a lot of silos, which are functional specializations that each do a step in the process of creating value like a factory. And there’s lots of very detailed business processes that are written down that you’re expected to follow. And theoretically that’s all supposed to create a lot of efficiency. And maybe it does when you do the same thing a million times. 

Jim: It never does. Anytime you have a group of people who are designed to focus internally and not talk to the rest of the organization, you have a silo. Anytime you have a system that designates the structure of a silo, you have a bureaucracy. But every person on that team should be talking to the customer. Every person on that team should be talking to other teams about ways that they can help them because they’re not employed by the team. They’re employed by the company.

When we’re working with teams, we’re like, what do you all need to get your job done? What’s the information you need? How do you need to be treated? What kind of training do you need? What are your values? And then we translate those values into different visualizations. So a big value of Agile is sustainable pace. Limiting whip is just to build the actual sustainable pace. 

So the reason that this book exists is to bring to everyone, experiences by hyper-focused truly cross-functional teams in organizations that want to get work done. These stories all center around how do we, define the work of the individual, the work of the teams, and the creation of value, and make that into a seamless set of relationships. We make sure that the individual professionals are treated like professionals and then you have a team full of people who are decision makers, who are change agents, who aren’t afraid to act. 

When you guys, or I or anybody else brings Agile or lean or Kanban into a company, we’re always frustrated because we run into this wall of resistance. The wall of resistance is there because you haven’t done the exercises to be ready to launch Agile or lean. You need a culture of continuous improvement before providing processes for continuous improvement. And both agile and lean make the same mistake. They feel like once people see it, they’ll go, I’m enlightened. Oh my God, stuff is so much better now. I can’t believe I just never lived like this. But No, what they say is, damn it, I’m busy. Shut up and leave me alone. I’ve seen this crap before. None of it ever works. Go away. 

So what we do at the beginning of every Turner Construction project now, and what we’re doing with our other clients is we go through something that’s called a right environment exercise. So the right environment is an environment where professionals have what they need to do a professional job. 

We go in, we map out the work that they’re doing. We talk about the relationships involved in that work, not just in the team, but extra team. We talk about it from the inception of an idea all the way through to the end of whatever it is that they do to get that idea done. That becomes important because in every single software development team, we’ve worked with software developers who were previously like, I just want to code shut up and leave me alone. They stop behaving like that and they start wanting to know why they’re building, what they’re building and who they’re building it for. They become professionals and they stop being craftspeople. We’re at a point now where we can’t be software craftspeople anymore. 

So we map that out and we always find places where it’s like, here, you should have talked to sales here. You should have talked to r and d here. You should have talked to the CEO, or whatever. So we’ll build those new collaborative elements in so that when work is coming through, at some point, those other people will be involved. And the level of involvement is directly dictated by the needs of the work itself. So not that we’re gonna develop a new meeting called a stakeholder meeting, but the work itself has different needs from different people in the company at different times. We take a look at that team’s workflow against other teams. 

When you ask agile teams what their biggest problem is other than technical debt their second biggest problem is dependencies. Dependencies don’t exist. They’re a figment of your imagination. They’re entirely a structure of the bureaucracy of the company. So the work that you have doesn’t match the arbitrary teams that you’ve set up.

Murray: Yep. 

Jim: So we look at those things and then we go in and we run a series of exercises called a charter where we go through four consecutive exercises that define the culture of the team in a very actionable way. We want transparency. We want good onboarding, we want training. We wanna respect each other. We say, okay, if you’re gonna do that, then when we build out your Obeya, all of the visualizations in there are going to underwrite these cultural norms that you have.

The third thing that we do is we do a communications agreement where they list out, here’s all the information we need. Here’s the information that we regularly lose. Here’s how we always interrupt each other. Here’s the tech that we have. And then we build out a plan saying, where should information go so that you don’t ask each other the same questions all the time. So that you’re not buried in interruptions. And then we take all that information, drop it into a roadmap, and we actually give them a structure and a plan so that they have a culture of continuous improvement. After that, they can pick all of the things from the lean trees or the agile trees or the scrum trees or the safe trees or whatever that they want, because now they’re picking things cuz they’re informed about the work that they do, how they do it, who they are, and who they want to be.

That is what this book is about. And this book loves Agile. This book loves Lean, but this book is the book that is your prerequisites. If you’re going to have an agile or lean organization that’s actually going to be sustainable.

Murray: To go back to the first part, we talked about creating the right environment by understanding the system that people are working in. And then it sounds like you work on redesigning it before you actually create the teams that you’re working with. 

Jim: As you both well know, every, exposure to a group of people requires a different response. No one ever comes in and says inflict upon me your set process. Sometimes we’ll come in at the team level. Sometimes we come in at the organizational level. Sometimes we’ll come in like at the engineering management level. And for Tony Ann and me, the first thing that we need to do is just get an idea for where are the impediments to completion, professionalism, and a humane working environment. And then we will guide them towards wanting to fix those particular root causes of their other issues. 

One project, which is in the book that we were brought into was a company that had a bunch of teams and all of the teams were frustrated because nothing was getting done and they were fighting with each other. And so we got everybody together. We had them. Write down everything that their teams were doing. We put it on this big wall, and then we started to play with that information. So it’s like, how many of these things that you’re doing require the input or activities or collaboration of other teams? And they would move them around. And as we moved them around, we realized there was a database group that everyone was relying on. And the first thing that this group of completely wonderful well-meaning people did was start to beat the crap out of the product owner of that particular group. So it took a couple of visualizations, but we’re finally able to come up with a visualization where everyone in the company could see, no, you all have created a bottleneck by underfunding a cost center. And therefore none of your work is getting done.

And then we had to tell them, Okay, we’re gonna build this huge Obeya that everyone’s going to use. And they’re like, why would the whole company use one Obeya? It’s cuz we’re all working for database now. And they’re like, hell if we are. And then the CEO’s like, hell if they are. And so it took a little bit of arguing, but we basically said, look, in two months we can solve all these problems and your throughput is gonna go through the roof. Or you can continue to have massive system breakdowns on a weekly basis. And they’re like, but we have to put out new features. We have to put out new features. No, you have to have a working system. They built a beautiful huge obeya in this massive conference room . And 210 developers were all working on database issues for two months.

No one was ever assigned anything. There was a huge block of things to do. You would come in and you’d look at those things to do, you would find some people to pair with. No work was allowed to be done alone. And then when you pulled that ticket you created a second ticket and then you went over to this giant systems architecture diagram that we had, and you would put your ticket on anything that your work was touching.

So that everyone knew at any given point in time, okay, I’m gonna touch this section. I see these two people are working in it already. I better go talk to them. We built a completely collaborative, real-time feedback system to get through that problem and it worked like a dream.

Shane: 

As we know when we start to change things, it gets worse for a while. Do you find that people think that day one, this change is gonna improve everything rather than take the time it needs to make that improvement?

Jim: What I’m finding now is coach fatigue. I’m finding that people aren’t expecting anything to happen at all. People are weary. All the coach can tell them to do is the same stuff that they heard before. 

So the way that we get around that problem is we treat it like consulting. So we don’t come in and say, here’s the script. We come in and say, okay, let’s figure out what the needs are. And when people start to actually examine their work, they just start to do better. 

Murray: You’ve talked a couple of times about the obeya room. How should someone set up an obeyer room? What would be the contents on the wall of the obeyer room? 

Jim: Okay, the basic entry point is do you understand what’s happening and who’s doing it, and what’s stuck? And who needs help. 

Who needs help, is a really big thing. If I can see my team’s stuff and I can see the database team’s stuff, and I can see Some of it is gonna be workflow. Some of it’s gonna be metrics and KPIs. You need to have a burn down chart and a burn up chart and a cumulative flow diagram. But a big part of that is going to be opportunity analysis and problem solving. We want to understand the things that are impacting the flow of work. 

So you’ll find that the same problem shows up again and again and maybe one or two people work on it. No, don’t do that. You want to solve it together. Or if another team’s solving it, then you go do something else. 

Miro. And Iobeya and mural have become the tools of choice for me for doing online Kanban because you can annotate in a way that everyone can see the annotation. It’s not like you have to click five times on a ticket to find the specific comments. So you see the conversations developing in the visual control itself. 

If people go to personal kanban.com or they go and look at our YouTube feed, you’ll see dozens and dozens of different types of visualizations of work. Just ask yourself, what information do we need to know and then start to visualize that. And then every time someone asks a question about that visualization ask if the visualization is too complicated or doesn’t have enough information or doesn’t visualize it in a way that is working for people. But for God’s sakes, just get people the information they need to get their work done because otherwise they won’t get their work done.

Shane: Yeah. We see that big organizations hide information a lot. The shiny suit big consulting schemes come in people get pulled outta the organization and then they all disappear into another building or another floor because they’re doing secret work. And nobody else in the organization can see the information that they can see. They can’t see the problems that need to be solved. They can’t see how they can solve them and what they do every day. It’s And therefore, how can a team take a step towards achieving that strategy because they don’t have visibility of what it actually means. 

Murray: The big management consulting companies do everything in secret because our real plan is to fire a lot of people and we don’t want them to know that. That’s how we’re gonna get the efficiency savings. So all the management consultants and the executives get together and they talk about the problem but they’ve already got a playbook, so they already know what the answer’s gonna be. Then they use the playbook to come up with the new organizational structure that has a target of 15, 20, 25% less people in it. And then they change the organization. 

So the fundamental idea is the organization is frozen. We unfreeze it, we change it, we freeze it again. And the people who do the change are the executives. So executives think workers do. Executives change things, workers don’t. And, Kanban is almost like the. opposite way of thinking. Jim, what do you think?

Jim: Yeah. If you can build a system where the people in the organization understand what’s happening in the business, what’s happening in the market, and how they can behave professionally, they will generate new opportunities for the business. 

What’s frustrating is people at work are overloaded largely because they were hired into a system that, by nature was ridiculously inefficient. And they’ve been hired to just throw bodies at that inefficiency. So then that happens until it becomes no longer economically feasible. And then they fire all those people and then over the next two and a half years, they hire them all back again because the system is still just as screwed up as it ever was.

So if you’re firing people because they’re not good team members then that’s great. if you’re firing people because you’re an idiot administrator who overhired and just doesn’t know the actual nature of the work, that’s not great. watch companies who otherwise should, be better than that engaging in this Jack Welch purge mentality that I absolutely don’t agree with. I think there’s a million ways that they could create more income while keeping people employed.

Murray: Yeah, so maybe we should go to summaries. Shane, what do you think?

Shane: Sounds like a plan. I like this idea that we should focus on what do people need to do to get that work done. 

You described Kanban as to see work coming up, see the work we are doing, and see the work we’ve done. And then the second rule, restrict your work in progress, that’s it. Nice and simple.

So I think I’m gonna start talking about Kanban boards where we restrict our work in progress and scrum boards, where we don’t, where everybody’s got five tickets under doing at one time.

You talked about building a building this idea of constant redesign. We all had this theory that if I’m building a motorway, it’s a waterfall project. We had a motorway built in New Zealand. It was over time, it was over budget. So this idea that actually nothing really is known. That actually you start the build work before the design works finished, So that you are refactoring as you go. 

I like this idea around you’re in a factory where there’s bottlenecks in the flow of information and there’s bottlenecks in the ability to make decisions. And those are the two things we wanna remove. Everybody can see everything if they want to. Everybody can make a decision if they need to. And that’s what we should be striving towards. 

And then you talked a lot about this idea of set the culture of continuous improvement before you start bringing in any processes or practices or patterns. Often we get bought in to help a team and the organization’s not agile. It doesn’t continuously improve in any way and we just suck it up. But ideally, if you can set that culture, you’re gonna have better chance of success. 

You mentioned dependencies are a result of bureaucracy. And it means that the team structures don’t match the work to be done, and therefore we have handoffs. Therefore we have dependencies, therefore, the system’s not working. And we all know the answer to that is build teams that can do the work themselves without relying on anybody else. 

The other thing is I’m a great fan of patterns, scrum patterns, lean patterns, kanban patterns. Things that other people have done that had value when they did it, given a certain context. I like this idea of picking patterns from the agile lean tree. Just go and pick what works for you, see if the leaves work for you. If they don’t throw ’em away and go pick some others. 

And then the last one I’ll end with is the idea of coach fatigue. Next time I get engaged by a customer to help coach, I’m gonna find out how many other coaches they had before me to see whether I’m walking into an organization full of coach fatigue. So that was me. 

Jim: So there’s a George Orwell quote from the animal farm days that all revolutions end up resembling that which they overthrew. So agile now is just very small waterfalls. And that’s not a problem. It’s just what it is. We didn’t want product managers and project managers anymore, but we recreated them with four legs. The two leg ones were bad, but we made four leg ones and they’re good. And then they ended up being exactly the same as the two leg ones. 

So there are some universal truths about how we work together and how information flows and the need to make decisions of different types in different ways and different times. And that is why we keep recreating the same managerial stack.

So at some point we’re gonna have to sit down and say, okay, if we want to behave in a way that is professional, respectful, and humane, and we now have access to completely instantaneous information transfer. What is the role that we actually need those people to play? Because right now, the role that both the product owner and the scrum master are throttling communication, even if it’s unintentionally. So if you ask them if they’re doing it, they’re gonna say, of course I’m not doing it. But if you look at it callously then they absolutely are. I’m not saying don’t be a scrum master anymore. I’m saying figure out where you are stopping information from flowing and where you are stopping your team from understanding the work that needs to be done. And alter that behavior. 

Shane: I think they should be the Scrum coach. They’re there to support the team, they should be behind the team. They should be coaching the team when the team needs coaching. They’re not the master. They’re not in charge of anything, they’re not at the front of the team. They’re not controlling anything. They’re just helping a bunch of other people do better work if they can. So that was me. Mary, what do you got?

Murray: You talked about coming into a team and creating the right environment by understanding the impediments that the team are dealing with and then helping to solve those before you set up the team. Makes a lot of sense. Hard for a lot of people to understand though, cause that means that you’ve got this array of patterns and way of thinking, which you are applying to the situation. That included things like mapping out the relationships between different people and working out where the dependencies are. Then once you’ve formed the team you talked about chartering the team, so setting up and agreeing on what is the culture we want? What is the type of communication we want? And then after you’ve done those things, you can set up some collaboration environments and tools. 

The one you talked about most is the Obeya room, which is a planning room in English. And really it’s just a room that provides information. I suppose it could be virtual now on Miro. It’s a room that provides everyone with the information they need to make better decisions. Simple as that. So each team would have, its kanban board in there and they would have some graphs, some charts on their metrics and KPIs. And most importantly they would have some way of saying, here’s our opportunities and here’s our problems.

There’s lots of templates for doing that, but you don’t really care about that because the thing is that they’ve just gotta do it. They’ve just gotta have that information so they can radiate it. And the question is really, do you have the information you need to make good decisions? What else do you need to know? And it’s much better to do that with Miro and IObeya these days rather than Jira. So that’s basically what I got out of it. 

I think that most people approaching this are going to say, but what’s the pattern? What’s the template? What’s in the A four? What’s in the first box? What’s in the second box? 

Jim: Oh, a hundred percent. In the book, there’s a lot of patterns and a lot of examples for not just getting the right environment set up, but then also how to do collaborative planning, collaborative working, and then how to visualize the results. One of the things that I show in that is the evolution of a series of boards or rooms for a German company. To show that this company did this without going out and learning about a bunch of stuff. They knew the rudimentary elements of kanban and some other things but they just figured out the information they needed and then visualized it. And then as they went forward, they kept asking themselves, how can this be better? How can this be better? How can this be better? And each time it got better, it worked its way out to a larger and larger audience in the company. So now those boards actually cover the entire company every day. Everyone in the company is in that mural board. that’s pretty exciting. 

So the more important thing is not to worry that you don’t have a satchel full of tools already, but just to know that you and your team need to be honest with each other about what you want. The book is providing visual tools to do that. So if you are a distributed team right now, even spread around the world, you can get into Miro, you can do one of these right environment exercises and have that information. But the key thing is that it’s your information communicating with your people. There are different people who have different communication styles and there’s different types of work that demands different levels of visualization.

Murray: Yeah. 

Jim: The more unknowns, the more learning, the more complex your system is, the more visualizations you’re gonna have. And if you don’t have more visualizations, the more your system’s gonna break down. The amount of difference in the way that people are wired is extreme. More extreme probably than international cultural differences. And what we have found is visualizing work levels the playing field, regardless of what your learning style is. You can see what the victory conditions are, you can see what the impediments are, and you can get in and you can do it in a way that lets everybody bring as much of their energy and value to your team as they possibly can.

Murray: Yeah. And then you can create your own processes and roles and tools and question everything .

Jim: That’s my dream come true is a world full of people saying, and then we did this, which is how it was in 1999. Before it became get your csm.

Murray: Yeah, I remember those days. It was great. 

Jim: And people say it’s the wild West, but it was really when we were paying attention,

Murray: All right. That is great. So Jim, how can people find out more 

Jim: Oh yeah. So if anyone wants to talk directly to me or to Tony Ann De maria, or to literally thousands of other change agents worldwide, go to Modus institute.net and join the free community that’s there. There are literally thousands of agile and lean and unaffiliated change agents there that think deeply about this stuff all the time.

If you are one of those people who are a change agent, you’re trying to get something done in your company and you just keep running into walls. You’re not alone. There’s a lot of other people out there. The community’s completely free. Don’t worry about anything. It’s not like you come in and you’re inundated with ads. It’s just people who really care about this stuff, working with this stuff. I’m there every day. And if you come in weirdly enough, you can speak to me. Collaboration Equation. It is on Amazon au. You can all pick it up with the click of a button.

Murray: Fantastic. Love it. All right. Thanks very much for coming on, Jim. 

Jim: You bet. 

Murray: That was a no nonsense. Agile podcast from Murray Robinson and Shane Gibson. If you’d like help to build great teams that create high value digital products and services, contact Murray evolve.co. That’s evolve. With a zero. Thanks for listening.