Before Personal Kanban was published, I had Jim Benson on the podcast talking about team work. During the podcast I asked, “I noticed, on your website, where you talk about if you optimize your team and not your people, you’re not really optimized. I really like that statement. We all realize we have to make the individuals work to make a team work, but I noticed that the gradual progression from personal to team, and maybe even Agile to Lean. Can you explain that progression and what you mean by that a little bit?”
Jim Benson: A hierarchy or a series of levels going from a personal level to a small team level to the group level and so forth up an organization. The personal or the individual level is, “I am here, I am part of this company and I want to do a good job, and I simultaneously belong to a couple of different tribes.” So I have the tribe of me, the tribe of my group, and I relate to all of those differently.
But the level of difference between them becomes more pronounced as I become more disenfranchised from that group. I’ve seen many teams that operate very cohesively as a team, but they are outside of the organization. The organization doesn’t value them and vice versa.
Any productive group that is inside an object that isn’t part of that object is basically a cancer. So I’ve seen extremely productive, thoughtful, wonderful groups that act contrary to the needs of their organization, because of their disenfranchisement from that organization.
What I’m trying to do with using the Personal Kanban as a personal Lean. And then the Agile methods, and then the Lean methods is create information flow throughout the organization so that the individual feels like he or she completely understands what’s going on at all the levels up and down from that person.
What’s been my experience is that organizations are very good at blocking information and knowledge from being transferred from place to place. When that happens, the cohesion of the organization starts to break down. The more it is pronounced the more of a breakdown there is. Until you finally get people who are just like, “I’m going to come here. I’m going to act like I’m working. I’m going to get my paycheck. And I’m going to go home.” Because they don’t feel like if even if they worked they wouldn’t be producing anything that anyone cared about.
We use these tools. We use the Personal Kanban on the personal side. This is what I’m doing and this is how I’m dealing with my day. Your team members can see that or if you have a team based Personal Kanban you see at a task level what everybody’s doing. The team then has clarity around what’s happening around the team. This can be augmented with Agile techniques of the daily stand up meetings or retrospectives or even in some cases time boxing, in order to give coherence around the product that they’re creating.
Agile is a strongly team based approach. It was developed, because it was reacting basically to the same forces that I just mentioned. Agile was developed because previously there was only a waterfall approaches. What would end up happening is people would come up and say, “Here’s 250, 000 functional requirements, I’ll see you in six months when you’ve completed my software.” And then they would get to the six-month point and they say, “This isn’t what I asked for?”
That wasn’t a very good way to manage things so Scrum, and XP and other Agile methods came along and said look we’re going to come and we’re going to talk to you much more quickly. We’re going to talk to you every month, or every week, or every couple of weeks, and we’re going to show you these little packets of value. The great benefit of that is that it greatly increased the amount of focus within the team.
Some of the issues that I’ve had with Agile methodologies, and I’ve been working with them for over 13 years now, is that they’re so focused on the team, that the team stops looking outside of the team for guidance. The assumption is that since it’s an Agile group, the rest of the organization is like “Oh, well they’re Agile, so they can get things done really quickly. That’s all we wanted in the first place, was for stuff to be done faster, so we can start ignoring them too.” That didn’t work very well. Agile supercharged the team, but it disconnected it at the same time.
Using the Kanban in the team, the big team, that’s an information radiator, not only to those people in the team saying “This is what we’re doing, and this is what’s blocked, and this is how things are going.” It’s an information radiator out to the rest of the organization, because anybody can come by and see it at any time. It says at every moment what people are doing and since you can see what’s coming up in the backlog, it shows everybody what’s coming up. If anybody up the management chain can come and see what’s going on, and they can make decisions based on that.
From the upper side, the C-level and VP’s and so forth, ideally, those should be the guys that are feeding information into the teams at a rate which they can afford. When the team is pulling their tasks, those tasks should be in a queue that’s not necessarily decided by the team, but by the people above them.
Related Podcast and Transcription: Jim Benson Talks About Personal Kanban
Lean Sales and Marketing: Learn about using CAP-Do
Special Marketing with Lean Book and Program offers on Facebook