VIDEO: How to introduce Kanban without anyone noticing

Recorded at Lean Agile Manchester on 21st June 2017
Brian Carman: How to introduce Kanban without anyone noticing (in 5 easy steps)


Transcript

Before I start my subject, I'll give you a very quick introduction about me. I worked with Ian about nine or ten years ago, at a digital agency, as a project manager. Since then, I've moved on, and I ran a team of project managers over at the BBC.

As you probably know, they're quite agile. Lot of scrum teams, lot of Kanban for that. Then since I moved on to there, to another organisation, it's not very agile, and very traditionally minded. Iron Triangle very much in focus.

Let's talk about that a little bit. Actually said, 'Well we need to tie down this ... lock them into an iron triangle.' The subject of my talk is how to introduce Kanban, Kanban without anybody noticing in five easy steps.

I'm going to ask you questions. I know some of the people did. If you've got any questions for me, can you leave it 'till the end because it's not really fair, but that's life. First thing I'm going to talk about is Kanban. Now if you look out Kanban on various websites, they'll give you lists of things that Kanban is and isn't. I think there's three principles in Kanban. I think there's five properties or practises. I'll give you the three principles. Start with what you know. Agree to pursue incremental change. Respect the current processes.

If you look on websites you'll see those kind of things. Now the five properties is where you get some work. Five properties. Anybody shout them out? Five properties of Kanban? You had one earlier?

Limited work and progress. Very good. Let me put that on the board. Okay, while I'm doing that ... there it is. Limited work and progress. Any other ones? Okay. You got manage the flow. You've got to ... what's your Kanban board? You've got to visualise your work flow. Then make process policies explicit and improve. Collaboratively. Yeah. They're the five. I know there's other phrases and stuff like that, but this is kind of what I'm aiming at in my five steps, trying to get to that.

Also I want to tell you about the problems. For project C, you probably haven't heard of, but it might be familiar with you. Problem number one, project MOBN , no? Mentioned once, but now it's expect to have actually delivered. This is one you've been working on really hard. It's almost there. That was one that was dropped from strategies some time ago. Then the ultimate question, why do all our projects take so f-ing long? They're the problems we're trying to solve.

Five easy steps. How to implement ... oh is this ... Kanban in five easy steps. Number one: Agree and control vocabulary for your project statuses. Okay? Now when I'm talking about project statuses, I like to do about six. I'll get to it in a minute, but I'm not talking about rag statuses. Okay? How many rag statuses do you normally get?

Four. Okay. I'll come back to that. The ... I like six project statuses, and the ones I normally go with are requested, discovery, definition, in progress, live, and complete. You know? You write all these. There's a difference between live and complete, but the point is if you can agree with the people that like their iron triangles that the project is in one of these six statuses, yeah? Someone's asked for it, but before I actually do any work on it, I'd like one of you important people at the top to say, 'Yeah, that's worth working on.' Okay? We've got some criteria to move from someone asks for it in the corridor, to, 'I'm going to do it here.'

Discovery, you're going, you're looking around, you're looking options, you're looking at companies. Then you've got to go to definition. What are you actually going to do? Hold on, you've got a report, and you need someone to approve that report. You've got a definition of a status, and you've got a message from go to one status to the other. Oh, hold on. Making process policies explicit. That's working. To some extent you're managing your flow. That's good. It's important this is written down. It's clear what you actually mean by most of these statuses.

The second thing you need to do is learn to count. Okay? Every week, I should say that I'm looking at this from a project portfolio point of view. I'm counting the number of projects we got and where those projects are, what status they're in. It's not individual projects. At any one time, let's say there's 34 projects or something like that. How many in this state? How many in this state? How many in this state? What I did is on a weekly basis, just write that down in the columns. It's very easy to do, only takes a second. Then next week you need to write them down again, and write them down again. That's it. That's step two, just write this stuff down.

Step three, well, you've got to deliver these. These are your committed projects, yeah? You've gone through the definition, someone's approved it, they've given you a budget, you're off. In progress, live, up to complete. This is your pour mechanic. You're managing your flow from the right hand side. Also, it gives you the opportunity to limit your work in progress to some degree because if you concentrate on these, then you can put forward an argument which says, 'Well, if you're going to approve this project, you need to take into account what stuff we're already doing.' When there's constraint on actually delivering the stuff that's been approved, and we've committed to, we haven't committed to these. Okay?

Rag status. These ones: red, amber, green. Yeah, how's it going? Is it alright? Someone explaining to you in the corridor and asks you to do a project and you've done nothing with it, what's the rag status of that? It's the fourth option, not applicable. Doesn't matter. Yeah? I haven't got a date for it. I can't give you a rag status. It doesn't make sense. It's not a project. There's four rag statuses. You can say, 'No, it's not green. It's not red. It's not amber. It's just not approved, you know?'

Step four: report. On the front of my report that I send out, it looks like a Kanban board, yeah? Over here we got all our projects and we just use Excel to show it. These are the projects that are in this status. These are project that are in status. So on. Over here you can colour code them, red, amber, green, but I wouldn't bother this side of the line.

The last page of your report, is something about agile metrics. You use those numbers to produce a cumulative flow. Do you know what a cumulative flow is?

Yay. Excellent. Good. In your cumulative flow diagram, you've got your, 'How many are in each status?' From that, you just put it on the back of the report, to begin with, because you're doing this surreptitiously. Then you can explain to people, 'Well, hold on. This is our cycle time. This is how long it's taking us for a project that's actually approved, until we get it to be completed.' This is our lead time is how long it takes to get from here to here. When you actually show it to these people, this question here: Why do projects always take so f-ing long? Actually revealed that this was two times this.

Actually, the biggest problem we had was getting the thing approved in the first place. Once we were in process, actually the delivery was quite quick. Visualising the work flow, and as I said before, if you can concentrate on these, then you're realistically limiting your work in progress.

Last thing you'll be able to do is to use these measures, the work in progress, to solicit the discussion about improvements, yeah? If you want to improve collaborative, you don't want to get into a situation which is just opinion. You've now got some evidence and facts over a number of weeks. You've worked out cyber time. You've worked out lead time. You've worked out that actually this is where all your projects are stacking up. That's where your problem is. What's the problem here?

For example, actually we have a legal review here, because there's a lot of contracts in place. Actually, we can demonstrate that it was the legal reviews that were really adding elapse time to the project. We agreed we would talk to the legal team on a weekly basis and prioritise projects. Which ones are important for us? Can you work on those, please? It didn't necessarily mean you got more through put, but what it did mean is you got your priority's project through.

Then you can go and buy your wonderful white board and your post it notes, and have your meetings where you put your cards up like this, instead of sending out in Excel. Any questions? None? Alright.

Upcoming workshops

Lean Agile Boot Camp

27 Sep 17, in Leeds
FULL

Kanban for ITSM

13 Sep 17, in Birmingham