Mike Lyons explains Kanban's fourth practice: making team policies explicit and visible. Explicit policies like pull criteria, WIP limits, and classes of service improve flow by ensuring work is ready before it moves. Display classes of service as swimlanes, keep Expedite work to one item at a time, and know your lead time before committing to fixed dates.
Expedite can violate WIP limits but you should allow only one Expedite at a time (WIP limit on class).
Lead time.
Chapters
As a Scrum master, do you have definition of ready and definition of done for your teams? Well, in Kanban we would call those explicit policies. And so our fourth Kanban practice is make policies explicit similar to definition of ready and definition of done. It's the same idea of making these agreements or team working agreements, highly visible and easily seen by everybody. They're created by everybody on the team. No one really sort of comes in and assigns them when we want to build these policies together. And each workflow step can have its own policy. Heck, I've seen teams have sort of almost definition already. How's work going to come into this workflow step? Definition of done? How's work going to exit this step? Whatever you call it, however you do it, it's about making the policies explicit or well understood. Are you tired of being in seemingly endless meetings in order to get to a decision to find common ground? Well, check out Murmur. Murmur is an online collaboration tool for teams that can help you make better decisions with fewer meetings. Now look, I'm all for decentralized decision making, but sometimes it just takes too long. Let MERMUR provide for you the process and collaboration space needed to make decisions quickly and efficiently. It has a built in three round process that asks everyone, is this safe to try? So even if you disagree, you you can still make progress together. So if you're drowning in meetings and endless slack communications about decisions, give Murmur a try. So check it out murmur.com and help your whole team make better, faster decisions. When we make policies explicit, it actually creates better flow. Why is that? Well, because we know we have all of the materials, all of the information, all of the understanding needed to do the work before we begin the work. The biggest inhibitor to flow is taking on work when you're not ready to do it. It's like, hurry up and wait. I've got to wait for approval. I need somebody's signature. The wireframes aren't ready, the documentation repo isn't ready, the whatever. Don't pull in work until you're ready and use explicit policies to help you do that. What are some sample explicit policies? You might have pull criteria? What's it going to take for this piece of work to be pulled into this next workflow step? WIP limits work item types, classes of service, dependencies, blockers. Now I want to go deep on a couple of these policies just to bring some awareness. They're really going to help you. I think these are two that you should have and they're work item types and classes of Service. So here are some sample work item types you might have on your team. Enhancement, refactoring, defect, maintenance. You might have others, but this is a good place to start. Okay, you can probably guess what I'm about to say next. It's your turn. Yeah. It's time to make this real. So think about in your situation, in your work environment, what are some of your work item types? You probably already have patterns in mind. You see these things all the time. Scrum Masters, what are your work item types? Write those down, jot those down, put them in your tool. If you've got your tool ready, go ahead and enter some in. Just get a good enough first cut because we're going to review this with the team. So go ahead and pause here and do that now. Now, Scrum Masters, in your work, you have classes of service. You just probably don't call them that. Sometimes you have the standard class of service. That's just how we treat everything. But what happens when there's a deadline that's approaching? Maybe it's a statutory deadline or a release date or an upgrade that has to happen before something's decommissioned. Well, that's a fixed date class of service. Another class of service you're probably experiencing today is when we respond to security vulnerabilities. Maybe there's an emergency security patch that comes up. And so you might have a third class of service called Expedite. Now, just a tip from the field on Expedite, I would say those can violate our WIP limits, but you can only have one of those at any given time. And so what are we doing there? Well, we're putting a WIP limit on a class of service. Now, we would display these classes of service as swim lanes on our board. Not all classes of service need to do each of the workflow steps. For example, Expedite may skip the design step and just go right to build. Now let me ask you this. What piece of data do you think you need in order to accomplish a fixed date class of service? Yeah, you got it. Lead time. If you don't know your lead time for your work item types, how are you going to be able to hit a date or guarantee a date on a fixed date? 1. Well, yep, it's that time again. Time to make it real. So thinking about classes of service in your environment, in your particular workflow, what are some of your classes of service? Do you have like a fixed date type class of service? Maybe you have a unique class of service, something that is just special for your team. For your environment. That's great. Write that down, Jot that down, add it to your tool if you can capture those classes of service. And again. Good enough. First, cut that. We just want you to get some written down. So this is all starting to come together now as we get into our fourth Kanban practice. Make policies explicitly.
