#166 - The Kanban Guide You Should Know About - Colleen Johnson

[00:01:03] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me Colleen Johnson. So Colleen, looking forward for this conversation. We are gonna talk a lot about Kanban and how it can help teams to be more effective today.

Colleen Johnson: Great. Thanks for having me. Henry.

[00:01:18] Career Journey

Henry Suryawirawan: Colleen, I always love to ask my guests first to share a bit about yourself. If you can probably tell us your highlights or turning points that we all can learn from.

Colleen Johnson: Great. Yeah. I started out in technology kind of by accident. It wasn’t my career path by any means. I actually went to school for journalism and fell into working in some technical companies, really more on the QA side and helping with things like test, you know, manual testing, and slowly started to get more technical just by, maybe, by exposure. I learned C++ and I got into writing automated testing scripts in languages that were very similar to C++. And I did not love it to be honest. Coding was not my natural place. I think I liked being more on the people side of things and product side of things which was really still kind of an emerging space, I think, when I was really coming up in tech.

So I found myself doing a lot of consulting work. And really working closely with a lot of startups on how to build great teams and bringing Agile practices to those teams. And as part of that journey, you know, I think for most people in the Agile space, you start with Scrum. It’s a very natural place for a lot of coaches and Scrum masters to start out. I don’t think I ever really gelled well with Scrum. You know, I always felt a little bit like I was the team babysitter or the team mom. So I had a hard time in really embracing a lot of the roles that I was in early on in my career.

And I learned about Kanban. And all of a sudden it gave me, I think, a very data-driven approach to everything I was doing. So I didn’t feel like the team mom anymore, a team babysitter, and I was able to really help the team navigate how they were working from a data perspective and use that data to identify opportunities to improve. And I fell in love with it. And so it gave me a chance to really bring Kanban in at the team level for organizations I was working with. And as my career shifted, I focused really heavily on Kanban at the portfolio and enterprise level. So bringing all these practices of continuous flow to everything from ideation and product discovery all the way through to marketing. That’s where I really got interested in coaching Kanban and bringing Kanban into other parts of the business.

And we founded ProKanban in 2020. It’s also a COVID baby. But it really came out of a growing need to unify the Kanban community around a core set of practices and languages, which we did through the Kanban guide. And to really create a safe and inclusive space for learning. Unfortunately, I think in a lot of different parts of technology, there’s a lot of ego and it can be very intimidating when you’re new to the space to feel welcome and to feel like you can ask the questions that, you know, raise your hand and ask a question about something that doesn’t make sense. And so we wanted to create a community where anybody that was new to the space could do exactly that and feel like they could get some smart answers to the things that they needed to help them on their journey.

[00:04:59] Kanban

Henry Suryawirawan: Thank you for sharing your story. So I think it’s really interesting how you got into Kanban..

The first thing, I think, if we ask so many technology team or engineering teams, product teams is they would have said, we have implemented Kanban, right? So by looking at the Kanban board in some form of shape, right, either virtual or physical. So maybe in the first place throughout your coaching and all that is this the right practice? Or maybe in another way it’s like, what is Kanban in maybe in a short summary so that people can understand actually the essence behind it?

Colleen Johnson: Yeah. So it’s surprisingly simple and surprisingly hard to do well for how simple it is, right? So, you know, I think when we think about the goal of Kanban, Kanban isn’t a process or Kanban isn’t a methodology. It’s really a strategy. And it’s a strategy for optimizing the flow of value to your customers. And we do that through really focusing on three main goals. Efficiency, effectiveness, and predictability. And efficiency is are we doing the best work we can with the economic resources we have available? Super important in the current climate. Effectiveness is are we giving our customers what they want, when they want it? And predictability really equates to are we delivering within a certain degree of acceptable date uncertainty and understanding the risk associated with the dates that we’re providing to our customers.

Unfortunately, a lot of practices do one of those three things well at the expense of the others, right? So we can be predictable and we can hit a date, but we’re gonna burn everybody out and spend a lot of money in the process. Or, you know, we’re gonna deliver what our customers want when they want it, but we’re gonna sacrifice predictability and hitting dates and maybe sacrifice efficiency, because we’re just throwing a bunch of money and a bunch of people and people energy at being able to deliver what the customers want, when they want it. And so our goal is to balance those three things and to constantly be coming back to: are we working in the right balance of those three things?

And we do that through a couple simple practices. The first one’s obvious, and that’s what you said, right? It’s a visual pull-based system. It’s a board, right. And that’s usually where most teams stop, unfortunately. It’s like we have a Kanban board, we’re good. The Kanban board itself has a few elements that become really important. It’s understanding where work starts and stops. Having workflow policies, so what has to be true for something to move from one column to the next? And that can be really simple things, you know, like for something to be ready for test, it has to have gone through a code review, right? Or two code reviews, one from our team, one from another team, I don’t know. So those become your workflow policies of just a quick check for the team to say this is ready to move on to the next stage of our workflow.

In addition to that, one of the things that’s often missing is some way of controlling your WIP and managing the amount of work in progress. We tend to gravitate towards WIP limits for that, but they don’t have to be at every column on your Kanban board. You can absolutely work within what we call a system WIP limit, which is just we’re never gonna have more than six things in progress on our board at any given time, and we’re all gonna make sure that we’re holding to that overall system WIP.

And then the other element that’s very often missing is this concept of a Service Level Expectation, which I think is probably one of the more powerful things that you can provide to an engineering team for them to be able to manage their own work. That Service Level Expectation is really a team agreement based on past team data about how long should our work take, right? So you could say, for our team, 85% of our work is typically done in four days or less. And so if we know that, that is our Service Level Expectation.

Sometimes Service Level Expectation can feel a little heavy handed. So depending on the team, depending on the organizational culture, I just like to say this is your signal to go do something, right? If work takes four days, you as a team agree that you’re gonna do something about that. And for a lot of teams, we hear that Kanban is either scary for leadership or the teams feel like, oh, well, we won’t have a time box anymore to push against or a sprint iteration to push against and work will just take forever. Well, your Service Level Expectation is how you ensure that it doesn’t, and that happens at an individual work item level. So obviously, if you’re gonna manage your work against that SLE, you need to be able to see how long the work is taking.

And again, I think we make this more complicated than we need to. We tend to stress out about finding the perfect tool that’s gonna visualize your, how long has this been in progress against your SLE and… I usually just start out with teams by saying, stick the date that it started in front of the ticket name. So the first thing you see on the board is the date that it started, and you can drive your conversation as a team around what’s the oldest thing on our board. Is it too old, basically, right, is what we’re driving that conversation to so that you can take action. That’s really the whole point of all of this is how do we give the team the right information so that they can organize around the most important work every day.

Henry Suryawirawan: Wow! So hearing what you just elaborated, I’m sure many of us would have thought, oh, I don’t think I implemented all of that, right? In fact, in the preparation of this conversation, I read the Kanban Pocket Guide that is published by your team, right? There are a few things that I also learned, like something new, like the SLE, I wasn’t aware of that. And then a few other things that we are gonna talk about today. Thanks for sharing that.

[00:10:20] Work Item Age

Henry Suryawirawan: So the first thing that always people associate with Kanban, of course, the visualization and the work in progress. So I learned by reading the book is that one thing that you mentioned, the single most important thing is actually the work items age. If you can explain the misconception probably from the industry and why you think work items age is the most important thing in Kanban?

Colleen Johnson: Yeah. So I think when we think about work item age, there’s a couple things that happen, right? WIP limits. If we’re only thinking about implementing WIP limits, one of the very common reactions to putting WIP limits in places: But I can do more. I’m actually very good at multitasking, I can work on more things at once. But what we don’t see when we increase our WIP or when we’re pulling more work in is that there’s a cost associated with pausing something else. Always!

And so this is where things like classes of service don’t make sense anymore. Things like creating a way for urgent work to trump everything don’t make sense. And maybe you have to. Maybe you’re on a security team and that’s there’s no option. If there’s a breach that you have to pull this other ticket in. But as soon as we can see the trade-off that we’re making, we can start to have a more tangible conversation about the cost and the risk. Which is always missing is, is very often missing for a lot of teams from being able to have that conversation in a real meaningful way.

And so what that looks like then is if I come to you and you have something on your plate that you’ve been working on for three or four days. And I say, Henry, this new ticket just came in, this is more important. You can then say, okay, the ticket I’m working on, I should be done with tomorrow. I expect to be done with tomorrow. I can finish this and then pull that ticket tomorrow. Or I can pause this and pick that ticket up. But that means you won’t have this ticket I’m working on for probably another four or five days. Cause that’s how long it’s gonna wait while I go finish this other work item.

And that data is surprisingly easy to get. It’s cycle time data from your past work items. But it’s not usually how we talk about those trade-offs. And that’s where I think empowering the team, giving the team the ability to have those conversations that are based on data becomes so important.

Henry Suryawirawan: Yeah. So I think we all have this kind of tendency, right? We think we can work more stuff and in one time at a particular point in time, right? Either at work or either personally. What you’re saying is that we have to focus and maybe finish what we are starting. Or even don’t start at all if you’re still in the process of finishing the most important items, right?

So I think another keyword that you mentioned is pull-based. I’m sure in many teams it is actually not pull-based, but more like push-based. From the top, they have a few things that they want us to do and we just accept while everything is in progress, right?

[00:13:08] Calculating Work Item Age

Henry Suryawirawan: So maybe a little bit about work items age. How do you define how we calculate this age? Is it just like by work starting and finishing, but when it is starting and when it is finishing?

Colleen Johnson: Yeah, so the team really needs to have a conversation about when work starts and when work finishes. And while that sounds very simplistic and maybe very obvious to the work that you’re doing, there’s usually a lot more nuance than we realize in answering that question. Does work start when you start coding? Does work start when it gets prioritized? Does work start when it gets defined? Does work start when it gets requested? All of those things can be true. You can have more than one start point, but as a team, we need to know what we’re gonna measure and what we’re gonna take action on, right? The same is true at the end of that line.

So for a lot of teams, the question comes up is, when is the code complete, right? Is it done when I’m done coding? Is it done when it’s checked in? Is it done when it’s merged to master? Is it done when it’s deployed? So the same thing becomes very true around where does work start and where does work finish. Once you know that and you have a way to track that, then that’s how we gather the data. So we use that same start and endpoint to get our baseline for SLE, and that historical team cycle time will be our guide in that. And then, that’s when our clock starts, right? So we determine where the clock starts. Maybe it’s your to-do column. We’re gonna start tracking work from the to-do column, and then from there the clock is ticking and we’re using that against our SLE. The most important thing is that you’re using the same start and stop point for your historical data that you’re using for tracking the work that’s in flight.

The other thing that’s often surprising is that we include weekends in cycle time and in work item age. There’s often a little bit of panic in there, cause it’s like, but I’m not working and that’s not reflecting my actual, you know, my actual hands on keyboard time. But your customer doesn’t care, right? And they don’t wanna have to do the mental gymnastics of going, oh wait, it’s five business days from today. So Thursday, Friday, Monday, Tuesday. Oh, Monday’s a holiday. So Monday, so I might get it Thursday. No one wants to do that. We just wanna talk in calendar days. That’s gonna keep things really simple and make the math really simple for everyone involved. So we include weekends in all of our calculations for cycle time and work item age.

Henry Suryawirawan: That’s actually very good insight, right? Because I think one of the most important thing about work item is that if the age is bigger and bigger, right? That means the customer is still not getting the value, right? So I think what you’re saying is really insightful.

Colleen Johnson: Yeah, and you touched on a really, really interesting point, right? There’s so many Agile practices rooted around trying to estimate value, whether it’s business value, whether it’s weighted shortest job first, whether it’s cost of delay. But really there’s no way of knowing what the value of something is until we deploy it. And so if you think of all of that work that is half done, that’s on your board. That’s all basically risk and liability for your organization. It’s a risk from a code perspective. It’s a risk because you don’t know if it’s valuable. And the more you keep adding to that work that’s sitting there, that’s not deployed to a customer, the more you don’t know what’s valuable, right? And so that risk is compounding.

And so we like to talk about this concept of thinking of your work in small bets, right? It’s a book by Annie Duke. And the smaller we can get those work items, the quicker they move through our system, the quicker we know if we’re doing the right work, and the easier it is to pivot if we’re not. So that’s an important concept for thinking about your work items. Everyone wants to know, do they have to be the same size? No, they don’t. They just need to be as small as possible. You’re gonna get more benefit from that than trying to make anything the same size or trying to story point or fit everything into the same time box.

[00:16:54] Small Batch Size

Henry Suryawirawan: Yeah, I think this is also very important to talk about, right? The batch size. And you know, like people always have this confusion, okay, how should I slice it? How long does it take? How do you actually define the size, story points, you know, t-shirt size, whatever that is? So maybe in practice, the things that you always advocate to your clients, how should we actually break down our tasks, so that it’s a small batch size?

Colleen Johnson: Yeah. So it’s interesting. I am always surprised by how much we hold on to story pointing and how much we often hear, right? It’s relative sizing and it’s about complexity and it’s about the conversation. But it’s made up math, right? It’s just made up scale that we use on the front end of our process, and then we try to use it to forecast delivery after things are done, which makes zero sense, right? It’s this ambiguous number that we use to say, it’s a small, a medium, a big thing. But then we’re gonna say when it’s done, not looking at all at duration or how long it took that that’s how much work we got completed. It really is, it’s apples and oranges at the end of the day. But I know that that’s a very hard practice for a lot of companies to give up. They’ve invested a lot of time and a lot of energy in trying to get people comfortable with story pointing.

So one of the first things I like to do with the new team is keep story pointing. We’re not gonna take that away. I don’t wanna make anybody freak out. But what I do wanna show you is a cycle time scatter plot, which is all of the work that you’ve completed for the, let’s say the last month. And we’re gonna color code those dots by your story points, right? So that you can see all the green dots are three points, all the blue dots are five points. Let’s see if there’s any correlation to how long those work items took. Cause your scatter plot’s going to show you date completed and total cycle time for each item. I have yet to see in my career a team that is very good at getting story points equal to duration.

And so once we can start to have that conversation, I think the next step becomes what are we getting out of story pointing, right? We’re trying to forecast complexity and have these conversations. But really what matters then is how do we get it as small as possible so it’s moving through the system quickly? And how do we do that right before we start on the work? Because if we sit down and have a conversation about all of these stories that I think you might be working on in August, when you go to pull those in August, you’re gonna say, I don’t remember what these are. And I don’t know how we broke them up. And you might not even be the person working on them in August. We might have a whole new team pulling those stories.

So I think a great practice to implement is to say, as a team, before anything hits our to-do column, we’re gonna ask ourselves, do we all understand the scope? And is this as small as possible? It’s that simple, right? And it’s very lightweight. You can do it at a daily standup or a daily sync up meeting. And it doesn’t require hours of planning on the front end and review from the team and hours of conversation to get there. It’s those two simple questions and we tend to refer to that as right sizing. You can use your team’s Service Level Expectations as a guide for that.

So I used the example earlier of, you know, our team, 85% of our work is done in four days or less. If I go now and we use that as a guideline and we have new tickets coming into the to-do column, we can say as a team, do those seem like they can be done in under four days? Great. Pull it in, right? Is it as small as possible? Pull it in. And it’s just a much more lightweight approach to being able to refine our work. And to make sure that we’re doing it right before we start on the work instead of months in advance.

Henry Suryawirawan: Yeah. So getting it right before we start the work, right? I think it refers back to the policy. So as a team, right? So you have to really define the policy, when can we actually start doing the work? Because otherwise, in many teams, maybe this is the anti-pattern, right? They just have a few liners of story, you know, like a definition of the task. But actually there’s not much details in it, and they have to actually pick the work and then ask people around. So I think the policy is also another powerful thing. If you define it well, I think the team will be able to work much more effectively and efficiently, just like what you said in the beginning about the goals of Kanban.

[00:21:05] Service Level Expectation (SLE)

Henry Suryawirawan: Speaking about, you know, after we break it down to small batch size, so you touched on SLE, right? I think many people may not have heard about this term. So maybe if you can explain, you mentioned that we always look back from the history and count the SLE. So how should we start using SLE maybe in our reflection of the practice of Kanban or maybe even some reporting?

Colleen Johnson: Yeah. I mean, think of your SLE, um, excuse my French, but it’s your oh-shit signal. Like, oh shit, this is taking too long. And for a lot of teams, there tends to be this panic that our data isn’t right. Like the data’s not good enough or like we haven’t been doing this, so this data doesn’t reflect whatever new process or practice we’re trying to pull in. That’s where the flow metrics from a Kanban perspective are amazing because you have all this data, you’ve been working this way, right? And as you continue to work this way, you’re gonna wanna keep going back to the data and revising that SLE. So for example, if I go start with the new team, one of the first things I do is I go back and look at their historic cycle time since they’ve been working together. If they don’t have that, I look at similar teams in the organization as a starting point.

Let’s say we built a new team for a very specific project and I plucked a bunch of people from other teams. This team’s got no cycle time data, so I’m gonna go look, I’m gonna aggregate all of those teams together as a starting point. What becomes important when we start with that very first SLE is that the team is on board with all of this. So my first question is gonna be, hey team, are we comfortable saying that if something takes more than four days, we all agree we’re gonna do something about it? That’s it. It’s a working agreement, right? It’s a way for us to acknowledge something’s broken or that maybe I need help, like I’m stuck, and I need Henry’s, I need to pair with you, right? To be able to get this moving again. So first it’s agreement, an agreement to start somewhere.

But as we work together and as we’re actively managing our work against that work and aging work number and looking at like, okay guys, we’re at three days, we’re about to hit four days, what should we do about it? Um, I have capacity, can I help in some way and getting this ticket done? As soon as we start doing that, you’re probably gonna see your cycle times getting better, right? And so maybe in another month we go back and look at our cycle time and we go, oh, you know what? All of our tickets now, 85% of them are done in three days or less. Should we lower our SLE?

One mistake I see a lot of teams make is they look at all this data and they make their SLE three times that, right? So the data says it’s four days, but we don’t wanna hit that number, so let’s make it 12. Well, what good is that, right? The SLE is for you as a team to manage your work. And so I see a lot of teams set it really high ‘cause they’re like, we don’t wanna hit it. But the point is that you hit that number and that you use that as a driver for conversation and action. So I encourage teams to constantly be reviewing their cycle time every couple weeks early on in their Kanban system and at least once a month once they’re maturing their system and making fewer changes to it. But you should see that that cycle time number starts to get lower and that your SLE follows it, because as you lower your SLE, you’re gonna get more consistent, right, with your delivery and your cycle time.

Henry Suryawirawan: Yeah, it sounds like if people are padding up their SLEs, like it is used as a management metrics, so people don’t wanna see that you are failing to meet your SLE. And I think one important point you mentioned is about SLE is an internal metrics. Probably the most important thing, right? It’s for your team to actually measure your own performance. It’s not for some management metrics. It’s actually similar to the concept of SLO. I think that’s really interesting.

[00:24:46] Managing Blockers

Henry Suryawirawan: The other thing you mentioned, right. So if, let’s say in the typical work when we started the work, but actually things are blocked. So this is very common in the software world industry. So typically, for example, some dependencies with maybe external or it could be some emergency due to production issue. So tell us how should we handle this kind of blockage or maybe work cannot move on simply because of some factors that we didn’t factor in?

Colleen Johnson: Oh, blockers are so much fun. We love to work around blockers. I think just maybe as humans, right? It’s like I’m stuck, I’m gonna move this out of the way. I don’t wanna see this anymore. I don’t wanna think about this, I wanna go start something new. From a Kanban perspective, we keep blockers in their current column and mark them as blocked and they still consume a WIP, part of your capacity on your board, and they still are aging. The clock is still ticking on those items, because their work that started, their value that’s not delivered and their risk, that work that’s stuck is, you know, even if we can’t actively do something is a team, we still haven’t delivered that value to a customer. And there’s a risk associated with that work aging on our board.

Part of the reason we do this is because we want the team to talk about that every time they look at their board, right? What can we do to remove that blocker? But one of the things I hear most often is, we can’t do anything, right? We’re blocked by another team or we’re blocked by third party vendors. And so why would we keep this on our board if we can’t remove the blocker? Well, think about that if you need a manager to step in and remove a blocker or to go harass a vendor for you or to go chase down some kind of resolution for something that your team doesn’t have control over. As soon as you move that ticket off your board or put it out of sight, how does your manager know that there’s a problem? How is somebody gonna know that there’s an issue if you are working around it and staying busy?

And so we wanna keep those blockers present, because we’re escalating that there’s a problem by a work item age increasing, right? And being able to say, oh, you know this ticket’s been, maybe I’m blocked by the infrastructure team, this ticket’s been in progress for 45 days and 30 of those 45 days have been waiting for this other team. Again, that’s like a signal that you need to go do something about it. And it’s a powerful one. It’s like stepping on the scale, right? When you step on that scale and you go, oh my God, I need to run more. Like I, that number is up 20 pounds from Christmas. It’s a trigger. And the same thing happens with work item age. And it’s almost, I would argue, more important for blocked work than anything else. Because you know, as soon as we try to move the blocked work to stay busy, we’re covering up a problem that needs addressed.

Henry Suryawirawan: Yeah. And I think this is quite typical, right, in many software company. Again, like I said, So dependencies, especially if you work with multiple teams or maybe external dependencies, right? I think it’s very important to escalate that and not to always start a new work, right? Because if you always start a new work that means, yeah, maybe you are not controlling your WIP. And besides what does it mean by having a block item forever? So I think that’s also another question, right?

Colleen Johnson: Starting work is more-fun. I get it. I mean, I, I like starting projects. I like starting new writing things. It’s always more fun to start things. But when our job is to deliver value, all those unfinished projects just aren’t doing that for us.

[00:28:14] Stop Pulling More, Finish Open Work Items

Henry Suryawirawan: Yeah. And I think in your book you also mentioned a few practice which is quite common in the software world, right? So like ensemble work. So things like pair programming, mob programming, or even like swarming, like, so ask team members who have the work items to actually start helping you to actually focus on finishing your task.

Colleen Johnson: Yeah. And I-think it’s-important when we think about how we contribute to our team, right? We all have a tendency when we have capacity to go look at the to-do column. What’s the next thing I can pull? With pull-based system, I’m gonna go pull the next thing that’s available. But really when we think about flow and we think about getting things to done, if I have capacity, I wanna ask the question of what’s aging, what’s blocked. I’m gonna start with the oldest things. I’m gonna walk the board right to left and figure out how can I contribute my energy and capacity towards work that’s already started first. My last resort should be pulling something new in. And I think that makes a lot of developers cringe a little bit, cause it’s like, well, I don’t wanna sit idle, right? I have to stay busy. I have to be utilized.

But honestly, we’re creating a pile of work then that’s harder to keep up with the more we keep pulling into the system. And I always joke, I worked in restaurants before I ever got into tech and there were always signs in the kitchen that said “if you can lean, you can clean”. And so that’s what I always tell my dev teams. I’m not saying that you should sit on your hands, right. I’m just asking you not to start new tickets, but I bet you could probably go do code reviews. I bet you could probably go write some unit tests. I bet you could probably go research what’s next in the queue. Just don’t pull more work into progress. That’s all I’m asking.

Henry Suryawirawan: Yeah. It sounds like people are kind of like… this is the anti-pattern, quite common as well. People are more territorial silo, you know, this is my role. For example, I’m a developer. I will only write production code or whatever that is. Someone else will do the other job. So I think in a true Agile, cross-functional team, right, you should be able to pick up maybe each other’s work in some form of capacity, of course. But yeah, the idea here is not to pull in more work and, you know, getting things piled up.

[00:30:17] Optimizing Flow

Henry Suryawirawan: So you mentioned about flow, I think it’s one of the most important thing in Kanban, right? So tell us how we can first identify how good is our flow? So coming to the metrics probably. And what is probably some of the tips that you can give us software engineer team to actually improve our flow?

Colleen Johnson: Well, I think it’s such an interesting trend in engineering over the last, I don’t know, five to 10 years where we’ve had all this focus on continuous discovery patterns, right? From a product perspective, like how are we keeping that loop going of experimenting and pulling experiments in and then CI/CD, right? Like how do we make sure that we’re integrating regularly? But delivery and the flow of work to the customer has stayed very batched. And I blame Scrum for that, honestly. And SAFe, I think made it maybe even worse, because it’s encouraging us to work in these batches where things are going out in chunks. And I think early in Scrum days, two weeks was probably a great milestone to try to deliver every two weeks. But I think for most organizations, we could do better.

And it doesn’t mean that you have to put code in front of customers every single day. But getting them into production, I think with things like feature toggles, can be a great way to make sure that you’re always developing on top of the most recent code. And when we think about a continuous flow, right? It’s both ends of this. It’s what’s coming in and what’s going out. So continuous delivery becomes critical. Getting things out, getting things to done on a regular basis becomes critical. But pulling things in when we have capacity is also critical here.

And so another kind of anti-pattern in a lot of Agile practices is this notion of batching what we plan. So I’m gonna plan two weeks worth of work and then push it to you, and then I’m gonna go play ping pong or foosball while you work on that. And then I’ll be back in two weeks with a new list for you. But what happens tomorrow when there’s an outage and I filled the queue and I have a bunch of work, or I have a critical fix that I need you to pick up, and I can’t get anybody to pick that up. Or I could get you to pick it up, but I have to pause all this work that we started, right? That’s now gonna age and add risk and add half-baked code to our branch.

So when we think about that part, we have to think about how we balance a continuous flow model for what’s leaving the system and what’s entering the system. And I love to use the airport as an example here. We’ve probably all flown somewhere where we’ve landed and they’ve come over the thing and said oh, we’re gonna have to sit on the tarmac because there’s no gate for us to pull up to. It happens in Denver more than I care to admit. And I think my sister got stuck on the runway for like a couple hours at one point over the holidays, cause there was such a backup of gate availability.

Well, think of your team as the airport, right? You only have so many gates. That’s your developers. You only have so many gates for that work to pull up to. If work is coming in, if those planes are landing and there’s no gate to pull up to. You have a bunch of stuff sitting that’s not actively being worked because nothing’s leaving the system. We’re not creating space for that. And there’s all those unintended consequences we just talked about with that, right? From a risk perspective, a quality perspective, a value perspective.

So what we wanna do is we wanna try to meter what’s coming in the system to what’s leaving the system. And so throughput is the metric we use to do that. Typically, you wanna look at your daily throughput rate which is often not a whole number, right? Your daily throughput rate might be like 0.6. We get 0.6 tickets done a day. But then you can use things like your cumulative flow diagram to tell you how much work is coming into the system. If the number of things coming in every day is outstripping the number of things leaving, you got planes on your runway somewhere and that means you have work aging. And so I think that’s a really great way to think about the risk of pulling things in without things leaving and why we wanna try to balance those two numbers.

Henry Suryawirawan: So very, uh, apt analogy. You know the airport, right? I’m sure people would have better visualization now, okay? So if you pick more work that means more planes, you know, on your runway or either in flight, right, trying to touch down. So think about how you can manage work. And probably you mentioned just now, right? Have a daily throughput rate. I think that’s very interesting. And the other one is a cumulative flow diagram. So try to optimize those probably and you can probably have a better Kanban practice.

[00:34:37] Scaling Kanban Beyond a Team

Henry Suryawirawan: So typically Kanban I see is working at the team level. I’m sure there are better ways of expanding Kanban into more multiple teams or maybe organization. So this is probably the most tricky thing in many organizations, because some people think, you know, they have just too many things to do, too many things to work on. How can we apply Kanban maybe at the organization level?

Colleen Johnson: Yeah. You know, it’s interesting all the things we’ve talked about today of Service Level Expectations and arrivals and departures and cycle time, they apply whether it’s a single item, let’s say, a user story or a task or if it’s a feature, a collection of stories or if it’s an epic, a collection of features, like choose your nomenclature in your hierarchy here. But the same principles apply at every level. And I honestly think we tend to start with practices at the team level first. But I think in a lot of ways there’s almost more bang for your buck starting at that feature epic level first depending on the size of your company. Because that focus that you get from limiting WIP and focusing on work item age at the bigger ticket level trickles down to the teams.

So if I have, let’s say I’m… let’s talk typical features, right? So let’s say I’ve got five dev teams that are all part of a program that are pulling features from the same backlog. If every one of those teams is spread across three different features, then I have 15 features in progress, right? How long is it gonna take me to deliver 15 features if I’m making this much progress on them? Where if I start to limit my WIP at a feature level, and even if it’s as simple as one team one feature, that’s a great place to start. Now I’ve gone down to five features, right, instead of 15. And hopefully, I’m gonna deliver those features sooner, because I’m not spreading the team’s focus across multiple different things.

Now, there’s a lot of caveats there. That’s not always possible depending on your skillset of your teams. Whole different podcast, right? I would challenge that maybe some of the structures we put in place with things like Scrum have made our teams more fragile and have created more dependencies by making small teams than they’ve maybe helped. But really bringing that focus at that big ticket level, I think, is a great place to start and a great place to pattern the behaviors of focusing on work item age, focusing on limiting WIP, making sure you have great workflow policies, and then letting that trickle down to the teams next.

Henry Suryawirawan: Yeah, so your point about having more multiple small teams, right? Actually some people thought that it might help, but eventually they will be bottlenecks, dependencies, depending on your value stream, right? So if teams are independent and they don’t depend on each other, maybe yeah, it’ll work. But yeah, if things got convoluted, you have dependencies with each other, I think yeah, that may be a big problem for a company.

[00:37:21] Kanban in the Current Tough Time

Henry Suryawirawan: And before we actually started recording, you touched on a little bit about the recent layoff things happening, right? So it could be also partly because of this and how can we use Kanban during this tough time for many people who got impacted by this?

Colleen Johnson: Yeah. You know, I think regardless of your role in an organization or in an engineering team, there’s a lot of fear right now. The layoffs are touching a lot of people and a lot of different industries. I went through this same pattern in the early 2000s. I was laid off a couple different times from companies. It sucks. Like it’s a very emotional experience. It makes you question your own value. But at the end of the day, there’s also the people left there that are left still having to figure out how to deliver the same quality code and the same value to their customers without all of the people that they had there before.

And I think that’s where Kanban right now can be incredibly powerful for those teams and being able to manage the work coming in and manage that work at a consistent pace, right? We talk a lot about this concept of sustainable pace in Kanban. And if you think about, you know, if you have all this work that’s in progress and half your engineering staff gets laid off, now what? Now what are you gonna do? Are you gonna expect everybody to work nights and weekends to pick up that load and carry that same amount of work forward at the same pace? Well, managing things like WIP and managing things like work item age against your SLE is gonna make sure that we’re not burning everybody out. That we’re still working at a pace that’s looking at our arrival rate and our departure rate and balancing everything in between against the capacity of the team.

Colleen Johnson: So I think it’s critical right now, and I think it’s an easy place for a lot of teams to start. They’re simple practices, like I said, of data you already have. It’s just making a few things visible and actionable to the team. And I think it’s very important and empowering to give the teams a simple way to say, I can’t pull that right now. Or I can but here’s the trade off. Because I think there’s a lot of people that are burned out when a lot of people that are trying to figure out how are we gonna continue to do what we were doing with half the people here?

[00:39:33] Tools to Get Started

Henry Suryawirawan: Yeah. And I think one of probably the difficult part where people wanna push back is actually maybe they don’t have their work visualized or maybe some kind of a system where they can show that, okay, here are the 10 different things that I’m doing currently, right? So maybe about visualization itself, for teams who probably didn’t practice a lot or even if they practice Kanban, I’m sure it’s not like 100% reflection of what they’re doing. So maybe some tips that you can tell us, like how can we visualize work items better?

Colleen Johnson: Sure. Jira is the tool that everybody loves to hate, but it’s really not that bad for this. I think really where people love to hate Jira is when we have a lot of corporate structure that doesn’t allow us to modify workflows or modify kind of the backend systems that give the teams the autonomy to create a structure that they need for their work to flow in the right way. Jira is very workable for all of this, and you can even use Jira for feature level and epic level Kanban boards with what we were talking about around scaling. And you can get a lot of the metrics you need out of Jira and make work item age visible with that hack of putting the start date in front of the ticket.

I’ve even had teams use Trello. Trello, you know, if we’re starting out or we don’t have budget for tools, Trello used to have a funny plugin that as the cards would age, they looked almost like a pirate map. Like the paper would rot, which was kind of fun. And I’ve used Miro. Honestly, I’ve used Miro for portfolio level boards, because you’re probably not gonna get your executives to go check Jira. So Miro can be a nice way to create a visual board system. They have a Kanban board in there that allows you to set WIP limits and create pretty robust cards. So I think you can get creative with it, with whatever budget and tooling that you have available to you.

And obviously, I’m a big fan of tools like Actionable Agile that are gonna give you all these sexy reports and sit on top of your data. Not everybody’s gonna have the budget or the tools available to do that right now, and so I think you can get creative and come up with ways to track a lot of this in Excel and whatever tools you have available.

Henry Suryawirawan: Yeah. Thanks for some of the tips, right? I think tools definitely important. But also another important thing is you actually track what other things that you’re working on, right?

[00:41:45] Women in Kanban

Henry Suryawirawan: So the other thing that we wanna talk about today, Colleen, is that you are running this program called Women in Kanban. So tell us a little bit more here maybe for audience here, women who are interested in learning more about Kanban. What is actually this program all about?

Colleen Johnson: Yeah, so when we first launched prokanban.org, we partnered closely with some mentors from Scrum.org. And very early in our trainer, you know, building up our trainer community, we had a pretty glaring old white guy problem. And you know, I think it’s common in technology, but, you know, one of our advisors said if you don’t fix this with 40 trainers, it’s gonna be a lot harder to fix this when there’s 400. And so we really got together and said what could we do that’s different? What would I have wanted was a big part of this. What would I have wanted when I was 20, you know, around opportunity and mentorship? And we built a program around that.

And so every year we open up applications. The number of applicants grows and grows every year and continues to astound me with the caliber of women that apply. I wish we could just run that all year. It does take a lot of time, but we typically accept somewhere between 12 and 16 women for each cohort. And in that we run the Kanban classes. They take the Kanban courses, but really the magic of the program is in the mentoring. And so we run small workshops to help them become great teachers, become great storytellers. Even things like how to market and brand yourself, how to transition from maybe being an internal Kanban coach to being an external consultant. What does that look like? How do you start your own, you know, your own LLC so you can contract and do consulting?

So we have a lot of great conversations like that and everyone’s at a different point in their journey, and I think that’s what’s so beautiful about it. Some of the ladies have just graduated college. Some of them are trying to make a career change. Some of them are, you know, wanting to be able to leave the company that they’ve been working for for 10 years and become an independent trainer and consultant. So it’s a pretty incredible group and we work very closely together through the cohort. And then at the end, they go through the same process as trainers who apply go through, where they have to pass the assessment and do a peer review and teach back in front of other trainers.

But I think my favorite part is when they pass the program. What I see is a lot of the women that go through it continue to teach together, continue to support each other. Like this current cohort that’s going on right now, we have women from the 2023 cohort helping mentor that group and coming to the workshops and engaging with that. So it’s just a really beautiful support system that extends I think far past after they pass the program.

Henry Suryawirawan: So in terms of participants, right? Is it like a global participants if people want to learn more about this program, is there a place where they can find it?

Colleen Johnson: Yeah, there’s a page on the ProKanban website where if you’re interested, you can add your name to the mailing list and you’ll be notified of upcoming cohorts and upcoming application opportunities. So definitely get your name in there if you’re interested or if you wanna refer someone else to the program. It is global and we, I guess, learned a valuable lesson in 2023, which was, we can’t do a great job of being a global community leader and do it all in English. And so this past year, we ran our first cohort entirely in Spanish. We recruited Spanish trainers and we had them run the programs and all the mentorship opportunities. And so we had, I think 18 ladies that just are all about to graduate from the entirely Spanish cohort, and we hope to do more of these in 2024. We’re looking at a French cohort next. And so we’re trying to create more of these opportunities, because I think it’s not just important for equality and opportunity, but it’s also an important way for the trainers to engage with bringing new people into the community and mentoring them.

Henry Suryawirawan: Sounds really exciting. So for those of you women who are interested to learn more about Kanban and be part of this great community, do check out. I’ll put it in the show notes later on. So, Colleen, thank you so much for sharing about Kanban, about your program, you know, mentorship and sponsorship, right?

[00:45:50] Tech Lead Wisdom

Henry Suryawirawan: So we reach the end of our conversation, but before I let you go, I have one last question that I would like to ask you which I call the three technical leadership wisdom. So you can think of it just like advice that you wanna give to us for us to learn from you. So if you can share maybe your version of three technical leadership wisdom.

Colleen Johnson: Yeah. Well, I think there’s a couple things. You know, I would say when we think about flow and a pull-based system, a lot of times it feels like a very individual restriction, right? I’m telling Henry, he can’t work on more things. But when you’re working as part of a team, a lot of that piles up and rolls downhill. And so you have to think about all of this as a system, as a bigger system and your contribution to a larger system that’s at play. And I think when we think about the human elements of working with other people, that’s where the sustainable pace thing really becomes important. And not pulling more work in and creating a pile of work for somebody else to try to then speed through and catch up with and clean up is also really important. And so, I guess you know, I think Kanban can get a bad rap for being too data-driven. And I would challenge that maybe that data is the thing that makes our work more human in the end.

Henry Suryawirawan: Thanks Colleen. So if people would like to connect with you, they wanna ask more about this Kanban practice, is there a place where they can reach out to you online?

Colleen Johnson: Yeah, so our Slack community is completely open to the public, and you could find that link at prokanban.org as well. I would love to see you on Slack. That’s the easiest way to reach out to me or anyone in the ProKanban community with questions or feedback on what you see or what you would like to see more of or less of. I’m also on LinkedIn and Twitter and Threads these days. So you can find me on threads at Colleen ray dot j or on Twitter @scrumhive.

Henry Suryawirawan: Nice. So thanks again for your time today. I also want to share, right? So in ProKanban, you have this Kanban Pocket Guide. I think that’s really a great book, right? Please do check it out. So I read it in preparation to this and also I find a lot of insights. So thanks again, Colleen.

Colleen Johnson: Thank you.

– End –