Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking how much more I'd enjoy 3D printing if my printer wasn't so finicky, or maybe if I were more willing to

[00:00:33] Dave Adsit: tinker. I'm Dave Adsit, a VP of Engineering, and recently I've been thinking about whether I get more enjoyment out of the time I spent replaying games that I love or exploring new games that I haven't tried yet.

[00:00:48] Allan Stewart: Our topic for this episode is Kanban. I feel like Kanban has gotten very interconnected and probably confused with agile processes and agile transformations. Lots of companies have been using software, I don't know, the last 15, maybe 20 years, that increasingly have been exposing Kanban boards, right? You can get them on GitHub now. You can get them in a lot of different Jira and other things. Even places like Jira, which traditionally didn't have a view like a Kanban board, you had other views. You had other views for task management. But really, it's more related to lean. So we're going to talk about that today. So Dave, in your mind, what is Kanban? Like, why does it exist?

[00:01:41] Dave Adsit: Yeah, yeah, you're right. Kanban has been very much tied up in agile and lean for a long time. And I think for me, Kanban goes back to the story that I've heard about the origins of Kanban, right? Kanban, from my understanding, is Japanese for... signboard. And what does that mean? Like, what does that have to do with software development, right? So in the story, the Toyota factory put up a big signboard of all the jobs that needed to be done. And so they were all right there. And people could go to the board and see which of these jobs, you know, cards on these boards describing on this board, describing the jobs that needed to be done. Right. Which of these am I trained to do and have the tools to do at my station, right? Okay. So I'm going to pull one of these cards. I'm going to take it to my station. I'm going to work on it. I'm going to complete it. I'm going to make a note about what I did. And I'm going to take this board, this card back to the board and post it so that somebody who can do the next step knows that it's ready and can work on it. And so that's part of the origin of the idea of Kanban. And so for me, when I think about Kanban, my whole thing is there's two, there's two principle concepts that come to mind. And the first one is that I'm making work visible. Why do I want to make work visible? Because status is not a meeting. I should not be holding a meeting to have to share the status of something, right? The, these workers in this factory did not need to go confer with the boss or with each other, or, you know, have a daily check-in where they said, okay, here's the status of these things. They was just always visible on this big signboard. And so Kanban. Kanban is about making the work visible and about simplifying the process too many times. We get into some of the more advanced or more later emerging agile processes, and they just get very complex. And that's, you know, that's why you end up with a digital tool to track it. Some of the earlier Kanban boards that I used were post-it notes, Sharpies, and a whiteboard. So we would, the board, we drew. We drew the board on the whiteboard and then we used physical post-its. We of course all worked in person then, right? So we could, and now we can't do that, but I try to replicate some of that experience in my Kanban. Kind of miss it sometimes. Same. I miss, I honestly, one of the benefits that I feel like we've lost by using digital tools is the visceral physical reaction of completing a thing and moving it forward.

[00:04:22] Allan Stewart: Yeah. And as you're, you're telling that story. Yeah. It makes me think it's really, really founded, right? The ideas of Kanban are really founded out of lean because like, like this worker doesn't just sit there and say, oh, well, I am the, you know, car door maker. And so I'm just going to keep making car doors and you know, how many cars have been ordered for this month? Who cares? I'm going to make 700 million doors. Right. And sometimes we unfortunately do that in software. As well. Right. Which is like, keep doing the same thing or keep piling more and more work on instead of looking around and saying, well, what needs to be done right now?

[00:05:05] Dave Adsit: Yeah. That was one of the things about the Toyota production system is that it enabled the Japanese factories to create custom orders for their cars in a way that you don't get when you are trying to mass produce left doors and somebody else mass produces right doors. And you hope that they're being built at the same rate because you need two of them for each car. Right. So, and it's, it's doesn't matter to me as the door maker, it's somebody else's job to keep track. Right. In the, in this system, you're only doing the work that needs to be done and what work needs to be done is always visible to all of the workers.

[00:05:43] Allan Stewart: Yeah. And you mentioned making work visible, which you reminded me of the book by the same title by Dominica de Grandis. Yeah. And I feel like that book explains some really important concepts related to Kanban related to why these tools work in a lot of situations and specifically for software development and actually making work visible talks a lot about product development and things that are very akin to software. I mean, it has a lot of software references in there, which I think is very helpful. Yeah. When you're trying to learn about how to apply lean to software. But, but the first thing that makes me think is that we, we are, we're visual creatures and seeing a status is a lot more effective, right? And, you know, picture is worth a thousand words, kind of a concept there. I don't need somebody to tell me in detail all about how it's going. If I can just look and see, it's like, oh, it's still in progress. Oh, and tomorrow it's still in progress. And after four or five days, it's still in progress. Then we might have a conversation. Well, what's really going on here.

[00:06:57] Dave Adsit: You can use a lot of words to say, we haven't been able to get this done yet. Or you can just look at the board and say, you know, it's been a few days that you haven't gotten this done yet.

[00:07:06] Allan Stewart: Yeah. Or, or we haven't started that yet. Yes. And you can look at the board and see why it's like, well, what are you doing instead? Oh, oh, okay. Now I see why you haven't started on my thing. Yep. So, so yeah, that, that just being visual helps. Even if it's not always tactile with our digital tools, but then once it's visible, you can also start seeing, well, how much work are you doing? If you're not using something like a Kanban board, or if you've got a digital Kanban board that hides things too readily, then you miss out on seeing the full picture of what's going on. How much stuff are you doing? How much are you completing? How much is in your backlog? The book. Yeah. And it's really challenging, seriously challenging, challenging, challenging, challenging, challenging, happen that often, you might not think twice about it, but those things can really start adding up. So if you put everything that you're doing on the board and you discipline yourself to do that, then all of a sudden you start exposing your unplanned work and you can start thinking about, well, where are the sources? Why are these things happening? Which people are asking for work outside of the normal flow? And you start exposing dependencies. What work is dependent on other work, especially if you've got cross-team things that are going on, making the work visible. Those are just a few of the ideas in the book that I think are really valuable when it comes to, let's have a signboard that actually tells you what's really going on and not just the bullet, the three executive bullet points or whatever. By making all of the work visible,

[00:09:16] Dave Adsit: right? Including those ad hoc things you do, or even if it's a standard operating procedure, every Friday I run this report. By making all of those things visible, we can actually see where our time is going and whether our time is going to the most effective, highest value tasks in our system. And we can then start to manage it at a meta level and say, oh, this team is understaffed or they're working on the wrong thing. Or, you know, we've got a lot of people who are subverting that system. We put in place a system to prioritize work. And it turns out that everybody just found their favorite engineer, bought them a couple of coffees or lunches, and now they get a whole bunch of unprioritized, unscheduled work done, right? Those are the types of things that can happen. And if we make everything visible, we can manage all of that work and much more effectively.

[00:10:14] Allan Stewart: And I don't think you necessarily have to, spend a lot of time tracking time, right? Like even just the presence of like, how many of these cards are happening? And even if they're small, you'll look at them and be like, well, it's a lot of small things add up and you can determine that. But if you are using a digital board, it'll probably tell you like, when was this put on there? When did it get started working on? When did it get finished working on? And so if you do want to find out some of those reports, the good tools will give you that without, without any extra effort on your part.

[00:10:48] Dave Adsit: Right. Just put it on, put it on the board at the right time, move it to the right status at the right time and you'll know. Yeah. So, yeah. So I really like all the concepts that we've talked about from making work visible. It feels like a very strong introduction to lean concepts in general, but specifically around the idea that work should be visible and the status of work should be visible to, anyone who wants to know it at any time without having to disrupt a worker to find out the status of a job. Like that to me is a critical thing about having a Kanban board is that you don't have to ask. It's just there. You just look. So we've talked a lot about what, I mean, what is a Kanban board? There's things that, there are things that are critical to how you should use a Kanban board. You know, every software tracking tool, every work tracking tool use. There's so many of them. It's not even worth trying to enumerate them, but there are things you can do with them that are effective and things that you can do with them that are less effective. And so if we talk about using a Kanban board as intended, one of the critical things is that you should be pulling work, not pushing work. What does that mean? Really? That means when I have finished something and it has left my station. Now I go get the next thing and pull it into my station. Rather than having somebody who is upstream from me, pushing a big old pile of things onto me. You know, if I'm the door maker, I'm going to go get the card that says I need a left door. And then I'm going to go to the blanks and pick up a left door and take it over and stamp it. I'm not going to have somebody come to me with a pile of left door requests and a pile of blank doors and say, okay, make them. Because now I'm dealing with a lot of inventory and I've built up a queue and there's things like that. And, and we are not able to manage the work as well. I think we've probably all worked in a situation where there is the one guy who just grabs all the work. You know, he's, he's got, well, I mean, this is a little bit more related to whip, but you know, he's like, he's the only guy who knows the X or Y system. So everybody who has a question about the X or Y system comes to him and drops work in his lap.

[00:13:10] Allan Stewart: Yeah. And, and when he's in the middle of doing something, something else comes up. So, oh, this is more important. So your, your context switching. Right. So there's, there's constantly, constantly a lot of things going on, a lot of things in process. But if you use the Kanban board, the way that it's supposed to be is that you can never do that to somebody, right? You're not allowed to go and push work onto people. You have to wait until they're ready. And then they look at the status and they say, Hey, what should I be doing based on the things that are available right now? And then I will pull the next one in. That makes sense that I can do. And I think the other thing that that means if you're doing Kanban well, is that if you are done with something and you need somebody else to work on it, like, so you need to pass, you finished a task and you need to pass the thing onto the next person so they can finish up the feature or you're waiting for somebody to do a pull request or something like that. If you were physically there, all that stuff would still be there at your station, right? Like, like in the Toyota car making example, like you've got all your doors sitting there at the station. And so you don't have room to keep working. You have to wait until somebody else can come and relieve you of, of that, of that stuff. And, and in software, I think that that's just as important. We need to make sure that we're not starting on new other things, building up this inventory of stuff at our desks, even if it is just a digital inventory of, of the things we're in progress, but you actually have to, you know, Kanban helps you to finish things, not just start them, right? You have to get it done before it can leave your station. You can't start on something

[00:14:58] Dave Adsit: new. Yeah. Yeah. So that has a lot to do with whip limits, you know, output cues and whip limits, right? So we want to apply a work in process limit. We know that the human mind is not good at multitasking. It's slow at context switching. Especially complex contexts like software development tasks. And so we want to minimize context switching and we want to, and therefore we need to minimize the work we have in process, which has an out, an additional benefit of if it's, if we're minimizing the work in process and we're focusing entirely on that work, it's going to get done sooner. And now it's ready for the next person to pull it out of our station. So when we talk about your Kanban board, your Kanban board's not a great place to track every single idea you've ever had for your software a build over the next 30 years. It's definitely a place to track the things that you are committed to and doing and recently finished. One of the things that comes up when I start talking about how we don't push work onto people, they pull work is, but if they, if they're pulling work and it's not, it doesn't get pulled away from their station until it's done, it'll take forever. And I'll never get this thing started. That is really, I really need now. And it's super important. I think that the, the answer to that is that we need to minimize the batch size, just as a warning. Like if you are not seeing flow through your system and you've limited whip and you're doing a pull-based system, you really need to minimize your batch size. And that is another big challenge for product development. You know, we've got the tension between minimum and viable and, you know, minimum viable and make a market splash. Right. We've all probably heard those terms, but we want to make sure that we're delivering something that's enough to surprise and delight a customer, but not so much that it overwhelms them. And so we need to work hard on creating small batches of value that actually increase value for customers and flow those small batches through instead of trying to get everything we've ever imagined all at once, which is part of why we end up with so many projects and so much context switching. Because we're trying to do too much at once.

[00:17:17] Allan Stewart: Yeah. And it goes back to the idea of making those things visible. And if you were using a physical board, there's no way you would want to create a big backlog of stuff. Right. So like there's a natural tendency there. And in some ways I kind of feel like some tools have done us a disservice that they have focused more on tracking all the things that you've ever wanted to do. And the Kanban board was kind of an advantage. Yeah. rather than thinking lean from the get go and say, and making it disincentivizing people from creating those really long lists, because if you, yeah, if you did, if you had to write them all out on stickies, you wouldn't put 300 stickies on. Yeah. Yeah.

[00:18:07] Dave Adsit: Yeah. So when we talk about Kanban boards, one of the things that's really important from my perspective. And in fact, when I did a survey of tools, I put a lot of things in there that I thought were going to And I picked one that intentionally falls into this strategy. Like people are like, Hey, why do we use Kanban board X when we could use one of these other tools that is so much more complex and allows us to do so many more things. I, my answer is exactly, that's exactly why we use this one. It limits the number of silly things we can do with the Kanban board because the Kanban board is intended to make work visible and help facilitate of process. But the, the process of software development is all secondary work. No one cares about your process. What they care about is does the software meet their needs? We use a process so that we can create a continuous flow of value. The process is not the purpose. The process is unnet is probably necessary secondary work. And so I want a tool that is very, very simple. And we've talked about simple Kanban boards and Kanban boards have two things, two, two corners. where you can say, okay, we can only have one expedite card in the entire lane. Usually whip limits apply to columns. You know, we only want to have two things in development. We only want to have three things in ready for release before we release them. You know, like you usually apply whip limits at columns, but we can apply a whip limit of like one for the expedite lane. As a manager, you can expedite one thing and we will prioritize it above everything else as it moves across the board. Maybe it's because it's an emergency. Maybe because it's just something that a really important customer wants.

[00:20:19] Allan Stewart: Yeah. Or it can also be used. Swim lanes can also be used for different kinds of tasks as well, right? So we talked about making sure that you're putting your unplanned work and making things visible. If you've got your swim lane for, you know, this is all the other, other, other stuff that has to be done. It gives it a place to live, a place to be on the board and it's visible. It's not mixed up with all the other things that are trying to be tracked as you do that work.

[00:20:51] Dave Adsit: Yeah. And that, that's definitely true. I tend to use types or colors to represent that on my boards and just keep everything in the same prioritized list where it's like, we prioritized this list of work. Some of the things are, you know, bugs. Some of the, things are stories. Some of the things are customer requests and some of them are like, you know, different types of things, but they're all prioritized in together. One of the other swim lanes that I often use is the epic or feature swim lane. I mean, we have an overall feature set that we want to release and we're releasing small slices of, of functioning software. Like we may not be ready to release it to the market, until we finish the whole feature set, but we are probably ready to release it to customers when we are not customers, internal customers, internal users after each piece is done so that we can do more testing and validation and, you know, shorten that feedback cycle so that we can build a better product.

[00:21:58] Allan Stewart: Yeah. And sometimes you do release parts of it to a customer.

[00:22:02] Dave Adsit: Absolutely. Absolutely. One of the things I tend not to put on my, my Kanban boards or rather I don't create a swim lane for them or tasks. You know, I've seen some Kanban boards where it's like, you've got your epics, your stories, your tasks, and you do five tasks to roll up to a story and five stories to roll up to an epic. I'm like, okay, I don't like to break it down to that level for me. We might list the tasks that need to be done, but I don't, I don't find that I'm creating independent value just by doing the database table and releasing it. I want to, I want to have the UI that talks to the middleware that talks to the API that talks to the database, you know, as one thing. And that when we release all of those things, we've created value. So those are some of the swim lanes that I've used with different groups at different times and found value in. So we've got the, like I said, we've got the swim lanes, which go horizontally across the board. And then we've got the columns, which are, are represented, represent the different work statuses. So in the absolute simplest form, we've got to do doing and done.

[00:23:17] Allan Stewart: And in a lot of cases, that's good enough, right? Like, like if you're not sure how to structure a Kanban board, my feeling is that simple is always better. What, what's the simplest thing that you can, that you can do. And so that you've got the stuff that, you know, needs to be done. You've got the things that you're doing, you know, and you know, what's been completed a lot of times in software boards, I'll see some other, you know, your, your backlog, but then there's the prioritized lane. These are the things that we, we've decided, okay, yeah, this is prioritized. Or this is the, you know, the bug that just has to really get fixed next. Sometimes depending on the deployment process or the structure of the team, right? If there's like separate QA people, well, then maybe there's a, there's a point where it goes from development, into a testing column, or maybe you have to batch up your releases. And so you have to have something that's ready for release, but it hasn't been released yet. So those are all doable. Those are all States that you can be in and you can, you can make those, those show up. But again, I think simpler is better. If you can say, Hey, we're doing this and it's getting built and tested and it won't hit done until it's actually deployed out to production. Then it keeps everything simple and everyone knows, Oh, you're working on it and now it's done. And that doesn't have to go through a lot of extra hoops and gyrations.

[00:24:45] Dave Adsit: That's definitely true. I think the first thing to prioritize for is making sure that the work is visible. And so if you have different stations or different statuses or different teams, then make those realize those in your Kanban board, have columns for those, you know, that's the most important thing is making it visible. And I think that you should also use the full time, the fact that you are leveraging Kanban as a way to drive down the complexity of your process overall. Right now, my teams, all of my software teams use the same board structure and it has a, it has basically five columns. There's an imagined, I like to call the backlog, the things we've imagined the imagined column, because stuff ends up in there that we would like to see someday, maybe. Um, but. Yeah, I have found that my teams tend not to use this backlog very much. It's a fantasy wishlist. The fantasy wishlist has tended to move out of the Kanban board into other tools preferred by the product managers, where they can track the evidence that they've gathered for whether this is good or not good, or, you know, how many people will actually use this? What were the outcomes of the various customer calls that we did, whatever. So I have found that the backlog or the imagination column has moved out of our Kanban boards. Mostly the column still exists. Almost nothing is in it. So where our Kanban board starts is with our committed and prioritized columns. So we have two of these. One of them is owned by the product manager and that's the committed and prioritized product work, including new features, bug fixes, customer requests. Um, the product manager has full control over prioritization for that column. And the other is our engineering column. We have an engineering queue, uh, and we try to balance between the two. We try to do three or four product things, and then we grab an engineering card and we do that so that we can maintain the health of the system. And because it's an easy way to see the balance of the two.

[00:26:55] Allan Stewart: Yeah.

[00:26:56] Dave Adsit: So that's our committed and prioritized, which is actually two columns. And then we have our in progress column, which is where dev, uh, is happening. The, the PM, the developers, the UX designer. If we had, when we had QA, all of those people would be working on the things that are in progress. And we will just cycle on things in progress until that whole group of people, that cross functional collaborative team of people decides we have finished this. It's no longer in progress. It's now finished. And part of part of being finished for us is deploying it at least to a few months. probably deploying it all the way to our production environment, ideally behind a feature flag. And so we'll put things in done and things will sit in done for maybe a week or whatever, until the product manager grabs them all and then reports on them all and shares them with the rest of the company and moves them into the archive column where they automatically get cleaned up by our tool.

[00:27:58] Allan Stewart: One thing that I kind of like, if you're using a process like that, where you've got done, and then another, another place for like archived or, you know, okay, take this away now. Yeah. Yeah. It helps with product management and reporting, but I think it also can be good, a good thing to have some team rituals around it too. So if you have a weekly retrospective, for example, or, or, or at the end of your sprint, gives you a good chance to look at those and say, oh, Hey, yeah, these are the things that we got done and now we're moving them on and, you know, helps, helps people to feel, a sense of accomplishment and not just being constantly on the treadmill.

[00:28:39] Dave Adsit: Yeah. I like that a lot. And that definitely becomes more of a factor when you are operating in a lean flow based system. We don't have defined sprints, so there's not, you know, the kickoff for a new feature is done ad hoc. The deployment of a feature is done as soon as it's ready to be deployed. We don't hold on to them. We don't have a release train. We don't, because things are just flowing as they, are completed. We miss out on some of the cadences and rituals that you would have if you were following like a scrum process.

[00:29:13] Allan Stewart: So, so that's actually a good call out. When we were talking about how you're supposed to use a Kanban board. One thing I forgot to mention, we talked about pull work. Don't push it. We talked about setting whip limits on your column. Another thing that I've found can be really valuable when, when you learn about how Kanban boards are supposed to be used, you, you generally don't move things from right to left on the board. When I was first really learning about Kanban, I was like, well, why? Like, I don't, I don't understand. And what I've come to realize is that we lose a lot of information when we do that. So one reason to not move things left is because if you've started it, there's probably is work in process. One of our friends, Mike would say, okay, you can move it from in progress, back into prioritize, but you have to delete that code.

[00:30:07] Dave Adsit: Yeah.

[00:30:08] Allan Stewart: Because that half finished code is inventory, right? It's, it's something that's, that's going on. It's sitting there clogging up your station, so to speak, you gotta get rid of it or you've got to finish it. Don't don't let it sit there. But the other thing that sometimes drives me crazy is when people will grab a card and say, okay, this, this didn't get done all the way or yes, this was done. But we also now realize that we wanted other thing related to, and they'll grab the old card from the done column, drag it back to prioritized and add extra work into it. And then now all of a sudden, like if you're, I really like tracking number of cards. Like what you were saying, it, you can, you can use it as a very simple way to say, oh, are we balancing our technical work with our product work? And if you start grabbing stuff, that was done and putting it back to not done well, now you're, you're losing this information about how often it might still be there. The digital tools do a pretty good job of status tracking, but it's easy to get that lost. And it's much easier to tell how much stuff is really happening when you create a brand new card every single time. And you say, oh, oh, you wanted something else that we fit. We partially fixed the bug, but actually now something else is manifesting. Okay, well, new bug. Yeah. We flow that through. Oh, you wanted another little tweak to this feature. That's fine. New card, flow it through.

[00:31:43] Dave Adsit: It is easy to create new cards. It is easy to throw cards away. It is the cards themselves don't have value. The cards are strictly a representation of the value we are trying to create. And so we should not treat them as precious in any way. I, I agree with Mike. You should not move a card from an in progress, status back to a prioritized status, unless you are willing to delete your branch. You can, you can complete a card or you can abandon a card. But if you abandon it, you have to delete the, you undo all the work that you did, because if you don't, you're creating cognitive overhead and cognitive load and incomplete work provides no value. It's just an impediment. We talk about how functionality is value and code is a liability. Well, incomplete code is neither valuable nor, I mean, it's not valuable. So it's just a liability. We, we have spent a lot of time. I mean, we talk about clean code. We talk about refactoring. My team spends a lot of time cleaning up a bunch of incomplete work from the past. So if we don't plan on finishing something, we will just delete it instead of letting it clutter our system because we know that it's, Yeah. Easy to create new cards when necessary. And I do the same thing where I say, Hey, we are going to do 80% of this. Now we've figured out that the, the scope we defined, if we do 80% of it, that provides 80% of the value or 95% of the value. And so we'll ship this card and we'll split off a new card that represents that other 20% that we didn't do. And then we'll hand it back to the PM and say, Hey, we didn't do this. You can prioritize it or delete it. But we, we try to keep a card to track it as opposed to reusing a card. There's no reason to reuse a digital card.

[00:33:40] Allan Stewart: And I think when things start moving from right to left on the board or backwards through the process, that's often, that's often a signal that there's probably, there may be something that is pushing instead of pulling. Yeah. Which is why things are moving wildly.

[00:33:58] Dave Adsit: Well, and you can't, you cannot unstart work. You can only, you can only finish it or abandon it. You can't uncrack an egg. And so with my tool, I start tracking when we commit to work so that I can see the whole process. And I think there's a lot of value to, we committed to do this on this day. It took us this long to actually get it done. That's our true lead time for features. You know, if we look at the lead time from when the PM put it into the, into the committed column and said, we will do this until it's actually in the hands of customers. That's our lead time. And I want to know that. And I want to know that information because that provides a lot of value about how the system is working. And if we're trying to move things left and right and all kinds of things, it really most often I have seen people try to move cards from in progress, back to, from doing back to, to do as a way to avoid the whip limit on the doing column. And it turns out you're just fooling yourself because your brain is still holding that, that cognitive load. And you have to know that. as we are as we are as we are as we are as we are as we are as we are as we are as we are as we are as we are as we are as we are as we are as we are as we are

[00:35:29] Allan Stewart: as we are as we are as we are as we are as we are as we are as we are as we are on our board. I think the other thing that is important to note is a definition of done. I feel like done is the one that pulls stuff to itself. I get like, depending on how you want to, you want to think about it as like, okay, it moves to this last column because there's nothing else to do, right? There's, there's no other work to be done, but this goes around in agile circles a lot, right? You know, the definition of done and whether the work is done or whether it's done, done, or, you know, these other definitions, because it's important to be clear for your team. Does done mean that you've written all the code and it's off to wherever it goes for testing and, and operations eventually going to deploy it? Or do, does your team own deployment? Because it's done. Is that it's in the customer's hands, right? Now, sometimes a feature flag or something else will make that not true. So I might back off on that a little bit and say, well, but is it deployed to production? Could it be turned on at a moment's notice? Then it's done. Anything else is still waiting. You know, it's, it's in some, some other status that's not done. It hasn't been delivered.

[00:36:56] Dave Adsit: I think if I had to pick a definition of done, I would want it to, want the code to be deployed behind a feature flag and the feature flag to have gone through alpha beta and general release. And now all customers have it. And I've gone back and cleaned up the feature flag that is now unnecessary because it's in general availability. And I've watched it long enough to know that customers are actually using this feature and it solves the original problem that they brought to us. Now, is that the definition of done that we use on my team? It sure isn't. And also it's not the definition of done we've used on any of the teams that I've worked on recently. But that might be a place to think about,

[00:37:35] Allan Stewart: like you talked about different swim lanes for your epics or features versus the smaller, or like a feature set, right? And so that might be a good place where you say, well, our definition of done for the epic lane includes all of that stuff, but the definition of done for the smaller pieces. That, you know, it's like, oh, well, you can't do the whole feature, but you can, you can do the first piece of it, the second piece of it, the third piece of it. And those are actually shipped and deployed out there. Then yeah, that might be, that might be something where you can say those

[00:38:10] Dave Adsit: individual cards are done. Yeah, you're right. Slices and features might be done when they are deployed and epics might be done when we have validated that they solve the business problem. Yeah. So yeah. Interesting. So Kanban boards, it's a very powerful tool for making work visible so that you don't have ever

[00:38:35] Allan Stewart: have to have a status meeting again. And I would add to that, that the, the power, the utility of a Kanban board increases significantly as you learn how they're meant to be used rather than some unfortunate teams that I've seen who use it as part of their, their work tracking software, but they, they haven't really understood. Some of these concepts that came with the Kanban board, it was just introduced to them as here's a different work tracking software that you haven't used before, but the actual Kanban principles were never taught.