Listen now
Introducing Kanban
Eric Brechner, Author, Agile Project Management with Kanban, Career Coach and Founder at Ally for Onlys in Tech, LLC
About this podcast episode
🎙️ Keep teams in sync and that product 🚆 train moving using a visual Kanban board
Eric Brechner joins the podcast today to discuss how you can manage team or personal work using Kanban.
Throughout the discussion, Eric and Bill Raymond share stories and examples that explain best practices and guidelines you can use to deliver teamwork more effectively.
In this podcast, you will learn the following:
âś… What is a Kanban board (and how you pronounce it)
âś… Using columns to arrange your work visually
âś… How to define columns
✅ How to define work and “done rules”
🎉 Introduce Kanban boards to your teams!
Transcript
(transcripts are auto-generated, so please excuse the brevity)
Bill Raymond: I guess I’m kind of looking at it like this train going on a track or something like that.
Eric Brechner: Mm-hmm.
It’s what’s called a pull system. And so instead of pushing where designer’s just throwing designs at the developer and the developer’s like overwhelmed. Instead, the developer’s pulling it. And then the validation people are pulling it from the developer and so on. So no one’s getting overwhelmed, everyone works at the pace that they’re comfortable and you can notice when someone is stuck.
[00:00:24] Guest clip [00:00:24] Intro
Speaker: Welcome to the Agile in Action Podcast with Bill Raymond. Bill will explore how business disruptors are adopting agile techniques to gain a competitive advantage in this fast-paced technology driven market.
[00:00:44] Podcast
Bill Raymond: Hi, and welcome to the podcast Today I’m joined by Eric Brechner, career coach and founder at Ally for Onlys in Tech, and we’re going to be talking about Kanban and we’re going to introduce you to these concepts.
Hi Eric. How are you today?
Eric Brechner: I’m doing great Bill, how are you?
Bill Raymond: I’m doing excellent and I am excited about this conversation, and I think before we even get started, people may not even know what this is, but can you solve a big mystery for everyone? Is it pronounced "Kahnbahn" or "Canban"?
Eric Brechner: It is Kanban (Kahnbahn), it’s Japanese in origin, and that’s how they pronounce it there, Kanban.
[00:01:15] Who is Eric Brechner?
Bill Raymond: All right, great. Thank you. Well then with that, let’s go ahead and get started. I guess it would be a good idea if you start and share a little bit about yourself.
Eric Brechner: Sure. So I have been a professional software engineer since I was 16 years old. That’s a little while now. A little over 40 years, and I’ve worked in a large number of different kinds of companies, small companies, big companies. Most recently, I spent 25 years at Microsoft, where I was a development manager most of the time.
I spent some time as a director and as a lead and as a more of an architect type person. And over that time, one of my particular fascinations is how software engineering works. So not just the code itself, but the processes, practices that people use. And in that time I learned a lot of different practices and I started a blog talking about practices that I particularly like, and then I ended up writing a book about my personal favorite of all of these, which is Kanban.
[00:02:10] Agile Project Management with Kanban
Eric Brechner: So that’s _Agile Project Management with _Kanban and it’s become quite a popular book.
Bill Raymond: Yeah, and that’s how we found you and I read your book. It’s a great book. You’re an excellent writer, by the way.
Eric Brechner: Oh, thank you.
Bill Raymond: And it’s an easy read, I would say.
Eric Brechner: Yeah, I tried to keep it really short. My personal favorite book is The C Programming book. it’s that thin one,Kernighan and Ritchie, I think. And I just loved it because it’s just so short and easy to read, lots of examples, and so I was trying to emulate that with my book.
Yeah, well it works. Yeah. Thank you for that, and thank you for sharing with the community.
So we talk about agile on this podcast a lot and very often there’s a lot of terms that come up: Scrum, SAFe, iterative development, complex program management, LEAN, and usually Kanban gets thrown in there as one of those terms that people use.
[00:02:56] What is Kanban and how does it work?
Eric Brechner: However, we actually never sat down and just said, what is it and how does it work? So today we’re going to demystify this word, and I would love for you to maybe share an overview as to what Kanban is before we get started.
[00:03:10] Kanban a board used to track and see your work
Eric Brechner: Sure thing. So the reason why Kanban’s often mentioned with some of those others is that people like the concept of a Kanban board. So a Kanban board is just a board. It can be a physical board, it can be a digital board, and it has a bunch of what I like to think of as stickies, but they’re little cards that indicate the work that’s going on. And you can use these Kanban boards to track and see your work. So if you’re using Scrum or any of one of the other methodologies that you talked about, you can use a Kanban board to visualize your work as you’re running your Scrum sprint or whatever it might be.
So it’s used in conjunction with that.
[00:03:45] Kanban - project management method
Eric Brechner: But Kanban also is its own project management method, that you can use instead of Scrum or Waterfall or SAFe or whatever. So it has its own rules, its own methodologies for managing your work, making sure everything flows smoothly, make sure all the work gets done, figure out estimation and planning.
All of those things that you would expect from project management, you can do with Kanban, with a specialized form of that board. And that’s when you get into real Kanban that I described in the book.
Bill Raymond: Well, that’s great. Thank you. I appreciate that overview, and I’m sure people have seen images of this and you may not even know that it was a Kanban board, but it’s this concept of having a few columns, as you said, right? And you probably have some column that says, here’s the planned work, here’s what I’m working on, and here’s the things that are done. And it just flows across, you take the sticky note or whatever it is, and drag it from left to right usually, right?
Eric Brechner: That’s exactly right. And if you’re using Kanban as your project management method, not just as a handy board to see the work moving around, if you’re using it as your project management method, then that board has rules associated with it about when you can move a sticky from one column to the next, and it has rules about how many stickies can be in each column. And that’s how it kind of controls the flow of work, which helps you manage your project and work as efficiently as possible.
[00:05:08] Limits on the work on progress
Bill Raymond: Okay. So that’s an interesting one because I don’t think that that’s something that gets brought up too frequently. What’s that limit? What do you mean by putting limits on the work in progress?
Eric Brechner: Yeah, so all project management methods try and just get a hold of the work that’s going on and keep track of it, but alsomanage it. That’s why it’s project management. So the way that Kanban does this, as opposed to something like Scrum, so many people are familiar with Scrum and there are these sprints and it’s a fixed amount of time and you plan out work for that amount of time and that kind of controls your work.
In Kanban, the way it works is that you have limits on the amount of work that can happen at any given time for a particular step. So let’s say your steps are the typical steps, you’ve got a backlog of work to do, that’s just a long list of things. And then you’ve got your first step and that’s doing some analysis of it, maybe specification, you’re just breaking down the work into smaller pieces.
And then you’ve got your implementation step, then you’ve got some kind of validation or delivery type step, and then that’s it, and then you’re done. Those are your common steps.
A WIP limit would say at implementation, there’s going to be no more than say, five items being worked on at a time. And then for the breakdown step, there’s no more than say, two items that are being broken down or analyzed. The implementation step may be five items and it may be three items are being validated and delivered.
And when you restrict it like that, now that kind of acts like the sprint does in that it limits the amount of work that’s being planned and worked on at any given time, but it also smooths out the work and allows the team to be much more responsive. Because at any given time, if you have to change what you’re working on, it’s not impacting that much work. It helps people stay focused, there’s lots of good things about limiting your work. It’s one of the two fundamental concepts of Kanban.
One is visualizing work on a board, and the other one is limiting the amount of work in progress at any given moment.
[00:07:03] How do you decide how to limit that work in progress?
Bill Raymond: So how do you decide how to limit that work in progress?
Eric Brechner: That’s a real challenge with people who use Kanban, but fortunately there’s a simple way to think about it. First thing you do is figure out which of these steps, so I gave you three steps, kind of the breakdown analysis specification type step, the implementation step, and the validation delivery type step.
You figure out which of those is the slowest, which one takes the most time. Typically it’s the implementation step. Not always, but typically. Then for that step, you figure out, okay, how many people do I have to do that step on my team? Maybe it’s just me, Maybe there’s three or four of us, whatever your team size is.
And then for that, you say, okay, we’re going to have about one and a half times that, that will be the WIP limit for that step. Okay? So let’s say you have four people on your team and all four of those people are developers and they’re going to do the implementation. Well, then the WIP limit would be something like six.
Okay? And then you want it a little bit bigger because you give some people some flexibility. Sometimes they get a little stuck. Sometimes they need to switch between things, so you set it like that.
And then the WIP limits for the step before and the step after are sized so that they feed the implementation step and they pull things out of the implementation step at the same rate as implementation. And there’s a little bit of arithmetic for that, but arithmetic is pretty simple. Andin my book I supply an Excel spreadsheet that does the calculation for you, but the calculation’s pretty straightforward. You just want to match that speed. And by matching that speed you get nice smooth workflow, which is the, by far, the most efficient, you don’t have work building up in front, you don’t have work piling up behind, everything just smoothly works through, and you’re delivering as fast as you possibly can.
Bill Raymond: So when you say the WIP limit for a team of say, four would be six work in progress items at a time. Is that per person or for the whole team?
Eric Brechner: That’s for the whole team.
Bill Raymond: Okay.
Eric Brechner: Yeah. And it’s enough to keep everyone busy, while at the same time not allowing work to build up and just having all this stuff that you haven’t finished.
Bill Raymond: And do you put a timeframe around this?
Eric Brechner: No, not directly. So there is, you know, indirectly in that you want all of these work items, all these stickies, to take roughly the same amount of time and not too much time. So what that ends up being is roughly one to three days, maybe five days at the extreme, maybe just a few hours at the other extreme.
But generally speaking, you want it to be one to three days. And the reason you want to do that is to keep your flexibility. Also to be able to tell whenthings are going haywire. There are always some tasks that take much longer than you expect, and you want to be able to recognize that by saying, okay, if it takes more than a few days, there’s extra work here and I need to break this down further, split it up into more pieces, and then work on each of those separately.
Bill Raymond: Okay, so that’s some good advice. You have the list of things that you are going to do. The work in progress items are one to two per person in a team of four, as in your example. And we only keep things that are work in progress items in there. So when we move two out, then we bring another two in. Is that what I heard?
Eric Brechner: Yeah, that’s basically it. Now there’s some subtlety here, and this is where it gets into kind of project management. You count things in implementation even when they’re finished, if someone hasn’t started validating them yet, okay? Because you don’t want to pile things up waiting to be validated.
Okay? When you finish stuff, you want it to continue flowing. And it is the same thing on the other side as well, you don’t want things piling up, waiting to be implemented. So those WIP limits apply to even completed work until someone picks it up and starts validating it or delivering it or whatever the next step might be.
Bill Raymond: Okay, so if I am a lawyer working on a brief, and then I need to hand this over to someone to review this, to another business partner, that’s when it goes into the done column for me and into a work in progress for that person.
Eric Brechner: As soon as they take it, yes, that’s right. So lots of people with Kanban and it’s recommended, especially when you’re first starting out, it’s recommended to split each column, so the breakdown, the implementation, validation, delivery. Breakdown each column into halves, a Doing and a Done.
The WIP limit applies to both. It’s the same WIP limit overall for that column, but it allows you to distinguish between items that you’re actually currently actively working on and items that are ready to be picked up by the next step.
Bill Raymond: But they still count toward, you know, let’s say it was implementation, they still count toward the implementation WIP limit.
Eric Brechner: And you may be wondering like, well, what in the world do I do? Let’s say I have a WIP limit of three or five or whatever. And we’ve done all of them, they’re all on the done, but none of them have been validated yet. And now I’m not supposed to implement anything else? Well, yeah, you’re not supposed to implement anything else.
Nothing’s getting validated. You’re all getting **stuck up**. What you should be doing, of course, is helping whichever team is doing the validation delivery, help that stuff get validated, move it out, and then once it’s freed out, now you can implement more stuff. And that’s how Kanban actually manages your work, is that it forces you to address issues right when they’re happening because they’re obvious and evident on the board. You can see them on the board, they’re visualized. You have these WIP limits to prevent things from getting too backed up, and the board tells you right then and there, you don’t have to wait for the end of a sprint to do retrospective.
It tells you right then and there that, oh look, things are backing up, I better do something.
Bill Raymond: I guess I’m curious, what I want to do is even stretch that example out a little bit more, and I’m also interested in how we manage this whole backlog of work. But we’ll get to that maybe in a little bit.
Let’s just use a simple example. I’m a designer and there’s this new requirement that a user has for our software product.
So I’m sitting here as a designer and I’m sketching it and working on what I think it will look like and collaborating with people. So I have a board where I’m working on that, but at some point I have to give that to the developer. And the developer maybe doesn’t do those sketches and drawings and doesn’t, you know, they’re more about like, well now I need to set up a code environment and write that code and then deliver it to QA or something like that.
So, is it the case that we all need to have the same columns, or maybe you could walk through what the designer might see and what the developer might see?
Eric Brechner: Yeah, if they’re part of the same team and then there’s just a flow from one to the next, then they would share a board and they would have at least one column each, right. One column for each person who owns a different step. If they were separate teams and they delivered completely separately, the designer was delivering for multiple different teams, designer would have their own board. And each of those other teams would have their own boards. But let’s say they’re part of the same team and each would have their own columns. And generally speaking, people make these columns way too complicated and overthink it, and that’s unnecessary. You want to keep this simple. So, the general rule of thumb is you need just one column for one person’s work, okay? So if I, even if my design takes multiple steps, if they’re all those steps are done by me, and they’re all done in sequence, then that can just be one column on the board. There’s no need to break it up. However, if those multiple steps could be done by a few different people, sometimes they’re done all by me, but sometimes they’re done by different people. Well, then you do want to split them up so that you can track each person’s effort.
Bill Raymond: Okay, so the rule of thumb here is that each team member has, in our case, of a team of four, one or two items in our work in progress at any one time. I’ve got this column where I’m, let’s say the designer and I just have some sort of a generic label that says that work is being done on it. It doesn’t necessarily say, do the design work.
Eric Brechner: Yeah. Yeah. Right. It’s the design step or something like that. And then there’s a limit on how many items should be in that step. For you, it’d be like, let’s say it’s just one person, well then there’d be two items, because you kind of round up, so it’d be one and a half, and that rounds up to two.
So there’d be two items for you as your WIP limit. And then you’re passing those on to the developer. And if you design out two of them and you’re done with it, but the developer hasn’t started implementing any of them, well then you should be helping out a different developer working on a different project, something like that, because you shouldn’t be overwhelming the developer with designs.
Bill Raymond: Okay, each one of these columns has little Done section. So I have my column, I do my work, I shift it over to the little mini done column in that same column, and that means that it’s now handed off because the developer said, I’m taking this on.
Eric Brechner: When the developer actually takes it on, they’ll move it out of your column, your design column, and put it into their implementation column. And now they are working on it. Fantastic. And that’s because they’ve finished up some other works and now they’re working on it. And now you, the designer, can design the next thing.
[00:15:26] The pull system
Bill Raymond: Right. So I’m starting to notice here that I guess I’m kind of looking at it like this train going on a track or something like that.
Eric Brechner: Mm-hmm.
It’s what’s called a pull system. And so instead of pushing where you’re throwing these things at the developer, you know, the designer’s just throwing designs at the developer go, go and the developer’s like overwhelmed. Instead, the developer’s pulling it. And then the validation people are pulling it from the developer and so on. So no one’s getting overwhelmed, everyone works at the pace that they’re comfortable and you can notice when someone is stuck. Because work is piling up so someone is stuck. And when someone is stuck, you can see it, because again, it’s visualized on a board and you can immediately start addressing it. Like, oh, you know, what’s the problem?
You know? And get people unblocked to free up that work and have it run smoothly. And that works really well in today’s environment where a lot of teams now are doing continuous delivery, which is wonderful. And so there’s never a pause. You can just work smoothly with Kanban.
There’s no time periods, no sprints, nothing like that. You just work continuously and the work just flows. It’s like a train running through, right? It just flows through and at no point do you have to say, oh gosh, are things going well? Do we have to re-plan? Whatever. You’re always keeping track of how things are going.
You’re always moving things through. And anytime there’s any issue, it’s immediately evident on the board.
[00:16:44] Using Kanban for personal stuff
Bill Raymond: Right. Right. Okay. So that makes sense. And I have seen Kanban boards used before and sometimes as simple as to do, doing, done. Those are the three columns.
Eric Brechner: Absolutely. It can be as simple as that. A lot of people like using Kanban just for managing their own personal stuff, at home or their kids’ homework or whatever. And it works great for that. You just need those three columns. Just like you were saying, these are things that I need to do.
This is what I’m doing right now, and these are the things that I finished. And that’s it. And your WIP limit in that case would be something like two and good to go.
Bill Raymond: Yeah, after talking to you, I was thinking about this and I realized, I really need that for the podcast because we do a lot of recordings. You’re number three today. And I think what I started to get overwhelmed with was, which ones am I working on? How can I just make sure that each one of those flows through and we get the podcast published and I said, all right, well, you know what?
After talking to you, I created a Kanban board and it’s working actually really nicely. Some of them even have the ability to, if you’re using software anyway, some of them even have the ability to sweep over to a timeline view. So I can see, okay, this person’s being published on this Tuesday, that person’s being published on that Tuesday.
But the important thing here is that I know that I have everyone I have interviewed in that board, and I can then go through the editing process with my team and the production process with the team, and everyone knows what’s being worked on at the same time.
Eric Brechner: Yeah, it’s just brilliant to be able to visualize your work like that. And in addition to that, by using these WIP limits, you can also control your workflow and make sure that you’re not overwhelming everybody that you can move it through. And also how longthings are going to take, be able to plan, estimate, all that sort of thing.
Because you have those limits in place, you can really understand the flow of the work.
Bill Raymond: Yeah. I find it to be super helpful, but then I’ve also seen some of these Kanban boards where it’s almost like Kanban board bycommittee. And I’ll see something like 10, 20 columns, and it almost starts to look like a project plan where it’s like anytime something comes in, we have a column that says, write down the use case. And then another column that says design it, and then another column that says develop, and go to QA. And then all of a sudden it’s almost like they’re mapping out their workflow for how they do work. How do you think about creating these columns?
How do you, when you’re working with a fairly sizable team, figure out the columns so that it’s represented, but people also understand how they need to get the work done?
Eric Brechner: The way that I think of tools in general, and Kanban is a tool, is that it should be serving you. You shouldn’t be serving it.
Bill Raymond: Your team shouldn’t be serving the tool. So it should really reflect how your team runs. Most Kanban teams are relatively small, so obviously for personal, Kanban it’s just yourself, but teams, maybe six people, eight people, ten people. And for teams like that, they usually don’t have that complicated process that they’re going through.
Eric Brechner: However, you can use Kanban for very large teams. It’s been used for teams of over 70 people. And for teams like that, there may be many different steps that they go through.
So the first thing to think through is, okay, what is your team? What does it do, and what are the steps that team takes? And by steps, I mean steps that different people on the team could do. Again, when we were talking about this earlier, it doesn’t count as separate steps, if the same person is always the person who does each of those steps in that same order. That’s just a single step, even if they think of it in themselves as it’s multiple.
So in that case, you could have a board that had 20 different steps, if it was a really big team, and there’s 20 different people that do 20 different things. That could make sense. That’s a lot, that’s a lot to manage, but people have done it successfully on teams.
It’s not the common case. The common case is that there’s only a handful of columns, small number like we were describing. And it’s easy for the team to manage and visualize.
Bill Raymond: That’s how I started when I started building the board, is I started thinking about, well, we record the podcast and then we, what’s the next thing we do? We go and do an initial edit. And what’s the next thing? Well, we also need to create the link in our website and then we need to upload it to the service that, and so initially I had all of those different steps in columns, and what I realized very quickly was that we probably just need to do is take all of that and to say there’s the recordings that are going to happen, there’s the recordings that we’re editing so the backlog is the recordings we’re doing.
Right.
And then once it goes into in progress, the tools nowadays have nice ways to templatize things, and you can have it even put a template of tasks that go in there. So there’s like a little subset of things.
It says things like, all right, there’s a checkbox that says, okay, yes, I uploaded this to our editing tool. Yes, that’s been sent off to the editor, yes. We’ve worked on the social media posts, but it’s still just one column that says In progress, as opposed to all of the things that we have to do in order to release a podcast.
And I realized very quickly that if we do it that way and follow your advice of keeping it simple, it almost felt like the tool was trying to manage us.
[00:21:40] The policies of done rules
Eric Brechner: Yeah, exactly. You want to be in charge and also it helps to keep things simple. One of the other key aspects of a really good Kanban board, that we haven’t talked about yet, is what are called the policies, or done rules. And the idea of this is that every step has, just like you were talking about, almost like a checklist of things that say, yes, you’re done with that step. Okay. The implementation is finished. The design is finished. The validation or delivery is finished. And that looks like, it’s been code reviewed, it’s been unit tested, maybe there’s been some static analysis or some kind of security review, whatever it happens to be for your particular team, you’ve got a list of things. And that ensures that when the next step, when it gets picked up from the next step, it’s ready. You know, It also keeps everyone honest about what’s being done. But like in your case when you’re talking about the recordings, it also makes sure that everything that you expect to be done, you haven’t forgotten anything.
So very useful to have those "done rules". And typically what we do is just list them out at the bottom of the board. Or you know, if you use certain tools, there’s little highlight things that’ll pop up. You hover over it and it’ll show you what the rules are. That’s always a great thing to make sure thatthe integrity of the work that you’re doing and like you’re describing, it avoids having too many steps.
Bill Raymond: Right, right. There’s always those last minute things that we need to do to complete something, and it’s Friday, so you just move it to done and then you come back on Monday or Tuesday and you finish it. But what we’re saying is, no, it’s done when we say it’s done.
Eric Brechner: Exactly right. It’s done when all the things that you’re supposed to get done, there’s a definition of that and all those things have been completed.
[00:23:15] Backlog
Bill Raymond: Now let’s talk a little bit about the backlog because you know, this is concept of the Kanban, we just said, simple, easy columns to follow. So we maybe have a to-do section there that, that lists out things that need to be done. But you are saying that these items should be one to three days in length in general.
So what about the bigger effort? Is there some other column somewhere that says, here’s all the big things that need to get done. How do you handle that? Because when I hear the word backlog,I actually think of those two things. I think of the stuff I need to get done in the next week or two.
And then I think about the big ticket items that I’m actually progressing towards. How do we resolve that?
Eric Brechner: Yeah. So generally speaking it’s hard to separate those things in a backlog. Everything kind of goes together. It’s just a big list of things that you need to get done. Some of them are big, some of them are small. You just got a big list of them. And you have them ordered in some way or prioritized in some way, so that you know what the next thing is that you should really work on.
First step in a Kanban board, or at least the step before implementation typically, is a step that breaks down the work.
Sometimes that’s called a design step. Sometimes it’s called a specification step or an analysis step. A lot of my teams just call it the breakdown step, which is label it a breakdown, and the purpose of that step is to take whatever sized thing from the backlog, whatever the next thing is to work on, and analyze a little bit to see, okay, what’s in here? And break it down into lots of little steps. And then those little steps go into that breakdown steps done column and done portion of that column. And then those are the ones that go and get implemented. So you can break down right then and there, and that allows all the rest of the flow beyond that breakdown step to be nice and smooth.
[00:24:52] Estimation
Bill Raymond: And what does that breakdown step look like? How do you, what does an estimation process look like?
Eric Brechner: Estimation of course is something like, okay, when is this thing going to get done? How quickly can we get it done? How many things can we get done in a certain amount of time? And that’s really easy to calculate with Kanban. It’s not that difficult to calculate with the methodologies, but with Kanban in particular, it’s just really simple.
So the way that you do it is you just count up how many stickies, how many cards you go into the final done column over the course of like a couple of weeks. And you just count them up. Now you empty it out and then you let a couple weeks go by and then you count how many you have. That’s how quickly you do those small ones. That’s how quickly your team can do those small ones. Okay, so now you know the rate of the small ones, the only question then is how many small ones are in a big one? So if you’re looking at your backlog and like, okay, I want to know when the fifth item is going to get finished, how long it’s going to take?
Well, you just look at the items in front of it and you say, okay, how many small ones are each of those? And that’s a standard estimation, but it’s an estimation that’s very concrete. You don’t have to guess days, you have to guess, okay, if I were to break that down, you know how many things would be in it? Most people can figure that out pretty quickly. Maybe it’s not perfectly accurate, but they’ll get it pretty close. And then you know how long each one of those takes, becauseyou already calculated that for two weeks. So it’s very easy to do estimation.
Bill Raymond: And that estimation tends to be remarkably accurate because instead of estimated for one individual how most estimates are done, right, one individual says, oh, I think that’s going to take this long. You know how fast your team, as a team, finishes things and you know how fast that is in actual days, not in story points or something like that, but in actual days, you know how long it takes because you’ve actually measured it. And so the only bit of variability is maybe misguessing how many items are in a particular item, you know, in particular big item, how much it’ll break down. So is there some column with those big items in it?
Let’s say for example, that I’m working on an e-commerce store and we have to build our own brand new shopping cart portion of the tool. Like that, that could take months to do. How would we use Kanban starting with that big ticket item, we need to create a shopping cart and we know it’s going to take a few months?
Eric Brechner: Right, so there’d be the shopping cart item in the backlog, right? It’s a massive thing, but it’s sitting in the backlog and it has its own little sticky and it just says shopping cart on, right? Then it goes into the breakdown step. And the breakdown step, oh boy, I don’t even know the first thing about how to break this down.
This is just this huge thing, I think it’s going to take, three months, six months, something like that as a rough estimate, but I’d like to get that, you know, I’d like to get more detail on that. So I’m going to create a sticky for design this. Okay. And that’s going to be its own step and implementation for that looks like doing much research and prototyping and everything else.
So you’ll break down that, that just design this step into lots of little stickies. Actually go through all that work. Maybe there’s prototyping, proof of concepts, maybe there’s even some usability testing and all that sort of thing. So it goes through all that. This is for a big ticket item.
And the result of all that is a better breakdown. Now I’ve got a bunch of different new stickies for what it means to do the shopping cart. And then each of those could themselves get broken down. Maybe some of them are pretty big, some of them are small. And then now you’ve got your full set.
Bill Raymond: Great. So do you do that in one fell swoop or is that something you start breaking down portions of it and get that done for a few weeks and then continue breaking it down more. What is that typical process look like?
Eric Brechner: The typical process is that it’s done in one fell swoop, because even a shopping cart isn’t that complicated. But every once in a while I was making it a little more complicated to cover the most difficult case. But the shopping cart itself isn’t that complicated. But we do occasionally have major projects and for those major projects, yeah, that’ll go through a whole bunch of different iterations to figure out what they’re made of and how they break down.
But the most common case, that’s not the common case, the most common case is, yeah, it’s going to take more like a month rather than just a couple of days, and you can break that down in one fell swoop.
Bill Raymond: Okay, so it’s a good idea to try and think about the things that you’re trying to accomplish in one month backlog items, and then break those down into days so that we’re not getting too overwhelmed.
Eric Brechner: Yeah, but most teams in regular work, it’s just not even like that.
In your backlog, you’ll have things that take a couple days, things that’ll take a month, occasional things will take a few months, things will take a couple of weeks. There’s just all kinds of variation in the backlog.
And sometimes you don’t even realize it until you actually start taking a closer look at them. When you first got it, you thought, oh, that’ll just be a couple days. And you look at it, it’s more I’m like, oh my God, this is like three weeks worth of work. So the idea is you just put in the backlog, you order it based on how important it is, how urgent it is, and then when you actually move it into the analysis step, this breakdown step, specification step, when you move it into that step, then you look at it a little more carefully. Then you say, you know, you talk to a few people, all that sort of thing, you realize, oh, okay, this is going to be this many one to three day type tasks to do. And those all go into the done column for the breakdown step and work their way through.
[00:29:57] Managing the backlog with Kanban
Bill Raymond: Thank you for that. And keep thinking about, I keep putting my project management hat on, we’ve talked about a number of different ways to manage projects on this podcast, there’s Waterfall, there’s Scrum, there’s SAFe, there’s different ways to manage work. And I am thinking right now about my world that I live in, where I’m a project manager and in the project world in Waterfall, what we do is we create a giant project plan and we try to estimate everything that needs to be done and what all of the deliverables are.
We usually put those into a project plan and we try to keep them not more than two weeks, sometimes they go a few more. And it breaks down, and now you have hundreds and hundreds of lines in some sort of a project schedule where we’re listing everything out. Now with Kanban, I understand that we’re going to do the things that we can do.
But I am wondering what that backlog looks like, because I could imagine myself feeling super overwhelmed if there are 150 backlog items that are two weeks or more in there. So how do we kind of balance what goes into the backlog and when it goes into the backlog or do you?
Eric Brechner: You definitely do because you’re right, it’s totally overwhelming. I mean, it’s ridiculous, right? So Kanban has been for a single team, okay, now that team may be pretty large, but it’s not going to be hundreds of people, you know? And like I said, most of the time it’s somewhere between one and eight people, something like that.
Not that big. So for a team that size, yeah, they can have hundreds of things in their backlog. Because there’s this big plan that produced all those hundreds of things.
What I typically do is, there’s going to be three stack of these stickies, literally three stacks of stickies when you’re doing it physically.
And the first stack, that’s the stuff that we need to do right now. That’s the stuff that’s upcoming, and that’ll be in the backlog that actually shows up on the board in the backlog, and you can manage it, it’s a manageable set.
Then the next set of stickies is what we’re probably going to do when we finish this first set. And the stickies after that is other stuff people have asked us to do, and yeah, we’re not going to get to that for a while, that’s out in the future. So then what happens is you’re working through the backlog of stuff that was most definitely on the top and needed to be done in the relatively near future, say the next month or so.
Unlike Scrum or something like that, you don’t have to carefully estimate and figure out exactly the sprint or something like that. It’s just, yeah, we’re doing this stuff kind of next. So you’re working your way through it and slowly but surely, of course it starts going away because you’re nice, smoothly flowing through the is new trains running. and it starts getting a little sparse and you’re like, oh, are we running out of work?
Well, then you grab the second pile. And you pull out of the second pile, all the stuff that you’re like, oh yeah, yeah, these are now pretty important, and these are coming up and you start filling in your backlog. You don’t probably extinguish the entire second pile, but you put a bunch of stuff in there that seems about right because you notice it’s getting a little low and so you, you replenish it and then you keep going. And you just keep repeating that until your second pile is gone and you start looking at your third pile.
That’s pretty much how it goes. And of course what’s happening during this is you’re constantly getting requests for new things, because the world is not static and no plan stays a plan for long. Things always are changing. So as you get a new request, you’re inserting them and either you’re inserting them directly into your backlog because they’re pretty urgent or important to do right now, or everything in our backlog is more important than that, so we’ll put that into the second pile or in the third pile, and we’ll deal with that when that comes up.
Bill Raymond: That’s I think a very reasonable way of doing it. So there’s a sort of a prioritization that happens at the beginning, and then there’s a breakdown of that work, and that’s when you really start doing the work is when you have that breakdown.
Eric Brechner: Exactly right. And you know, There’s no reason to be, you know, have things that are not going to be looked at for months all on the board. That’s ridiculous. So that stuff goes into the second pile or the third pile, and then the stuff that you’re looking at is the stuff that’s top of mind that’s coming up soon, or you’re working on it right now. Andas you clear that out, then yeah, of course you look at the next things.
[00:33:48] Any specific roles in Kanban?
Bill Raymond: And I guess I’m curious, when we talked to, I’m just using Scrum as an example because we just did a number of different podcasts on Scrum, but there’s different roles that you define. You have a product owner, you have a Scrum master, you have a developer, you have a designer, whatever those different people are on the team, right?
And some of them have specific titles that mean very specific things. Now, does Kanban prescribe any specific roles?
Eric Brechner: Not at all. Kanban is just super simple, which it is, why it is overwhelmingly my favorite. It’s really, really simple, really easy to understand, really easy to use, really intuitive. It’s also continuous. That’s another thing that I love about it. There’s not these artificial times that, you know, you can do whatever you want whenever you want.
I’m not hard formed that way. And likewise, there’s no prescribed roles. That said, lots of teams really like the Scrum master role. They really like the product owner role or some of these other roles, or maybe they’re using a different methodology or Waterfall extreme programming or you know, who knows what?
And the team just really likes certain kinds of roles and the people on the team like having those roles. Well, you can certainly have those roles with Kanban. Nothing’s stopping you from having a product owner. Nothing’s stopping you from having a Scrum master to run your daily standups. Because Kanban uses daily standups and that’s when you can look at your board and see if there’s any blocking issues and that sort of thing.
So, you know, absolutely you can still have those roles if you want to, but as you said, Kanban doesn’t prescribe it.
Bill Raymond: Okay, thank you. And I guess we’re getting towards the end of the podcast and I really appreciate everything that you shared. It is fairly straightforward. I mean, if anyone has never tried using a Kanban board, you could just use it in your own life. Even if the rest of your company hasn’t adopted using Kanban, you could actually, there’s so many free tools, or even just the ability to put stickies on a wall to kind of manage the work that you are doing.
And it is very helpful, it helps you kind of keep focus on the things that need to get done. I’m one of those types of people that loves to try out different things all the time, and I’m constantly shifting around with those and I have to keep my focus. I know that’s something that I need to do, and so I’ve found it to be super useful even though no one ever told me to use
[00:35:53] Implementing Kanban with your team
Bill Raymond: it.
But I am curious, let’s say now that there’s a leader listening to this podcast right now that says, I would love to introduce Kanban for all my teams and I’m thinking this might be a way for us to improve the flow of our work and perhaps maybe get us all on the same page.
What would a leader do to start looking at implementing this with their team?
Eric Brechner: Absolutely. So few different steps, and this is all pretty standard change management for those people who’ve studied change management. But if a few different things. First of all, have a talk where it talks about Kanban, introduces people to the notion of it and say, this is one of the things that we’re thinking about doing here at the company.
Just to let people know that there’s this interesting thing that you’re thinking about doing. Helps prime them for a change. And then introduce it to a team that sounds interested, like, you know I might want to try this. And then have one team try it out. That one team you can get a feel as a leader for, okay, what do they need to know?
How do they set up a board? Do we want to use a physical board or an online board? How do they like thinking about it? What do we want to call the steps? What kinds of problems do they come up with as they’re trying it out? And then that team, which is acting like a pilot, that team then becomes pretty expert at Kanban, can figure out like an FAQ, or to answer questions that other teams might have if they want to try it. And once they get good at it, now you can do a few more pilots and use that first pilot as a bunch of experts to help you out. And then once a few teams have done it, now you have everything you need.
You know all the kinds of different variations, you got a bunch of people who can train other people and help out other people from those pilots. And there’s also going to be a buildup of excitement around using this really simple, really intuitive,flexible system, to get things done and to have your work run so much smoother and faster.
It’s so much less overhead. That’s what I recommend for that leader is, don’t jump right in and force it on everybody, but show it to some people and get some volunteers and try it out small and then build from there.
That’s great advice. I really appreciate your time today, Eric Brechner. If anyone wants to reach out to you and talk about this further, is there some way for people to reach you?
Absolutely. Of course I’m on LinkedIn, so you can just look me up there. Of course you can look at my book. I have some YouTube recordings when I gave talks to Microsoft and Google. And then if you want to reach it out to me directly, please come to my website allyforonlysintech.com
And thereI do career coaching, of course I coach people up on Kanban and general issues of project management and people management and just about everything. I love that work.
Bill Raymond: That’s wonderful. Thank you. And I will make sure that the links to your website and LinkedIn are on the agileinaction.com website and in the show notes, so just scroll down if you are listening right now to the show notes, the description, and you’ll see that there. And of course, I’ll also link to your book, Agile Project Management with Kanban.
And anyone that wants access can go and get that. It’s available on Amazon. Eric Brechner, thank you so much for your time today, I really appreciate it.
Eric Brechner: It was my pleasure, Bill. Thanks very much.
[00:38:54] Outro
Bill Raymond: Thank you for listening to the Agile in Action Podcast with Bill Raymond. Subscribe now to stay current on the latest trends in team organization and agile techniques. Please take a moment to rate and comment to help us grow our community. This podcast is produced in affiliation with Cambermast LLC, and our executive producer is Reama Dagasan.
Speaker: If there is a topic you would like Bill to cover, contact him directly at bill.Raymond@agileinaction.com.