Podcast Ep #75: Legal Workflow Lessons from the Factory Floor: Kanban for Lawyers Part 1

What does a Japanese automobile factory in the 1950s have to do with running a modern, efficient law practice today? As it turns out, there is a ton we can learn from it. And in today's episode, I'm going back to the roots of the Kanban method to explore how a simple visual system transformed Toyota's manufacturing process, and how we can use those lessons to make work flow more smoothly through our law practices today.

I'm going to unpack why visual systems are so powerful, why too much partly finished work, which is to say unfinished work, inside of a system creates real problems, and how shifting your mindset from a push-based workflow to a pull-based system will inevitably unlock smoother and more profitable workflows in your law practice.

This is part one of a two-part series. Next week, I'm going to go deeper into the Agile Kanban method and some specific techniques you can use when setting up your systems. But the lessons from Lean are powerful, and I don't want you to miss them.

You're listening to the Agile Attorney Podcast, powered by Agile Attorney Consulting. I'm John Grant and it is my mission to help legal professionals of all kinds build practices that are profitable, sustainable, and scalable for themselves and the communities they serve. Ready to become a more Agile Attorney? Let's go.

Hey everyone, welcome back. This week, I'm going to go a little deeper on a topic that I obviously touch on all the time, and that is Kanban boards. Specifically, I want to talk about why Kanban boards work, and specifically why they work for lawyers. It's interesting that this is something that I find that I wind up going into sometimes even with my longer-term clients because one of the great things about Kanban boards is they're pretty intuitive.

Once you see work in a Kanban board, it just kind of makes sense. And that's one of its incredible powers, but I also think that going a little deeper and understanding some of the rationale, a little bit of the brain science, a little bit of the history of where this methodology and this tool came from can really help you when you're setting up your own Kanban boards, when you're making choices about how to design your Kanban board, when you're working with your team on getting them to adopt Kanban boards, whatever it happens to be.

Partly I'm doing this, way back over a decade ago when I first started beating this Kanban for lawyers drum, it was a lonely drum. I was the one out there sort of heralding this methodology. I spent a lot of time basically just explaining to people what a Kanban board even is. And just to give you the very basics, way back when, I actually had a Vine, so the predecessor to TikTok where you had these 6-second videos, and I could build a Kanban board inside of a 6-second Vine, which is basically you draw two lines, which creates three columns, and then you slap labels at the top of each column.The far left one is to-do or ready, the middle one is in progress or doing, and then the final one is always done, and we really love that done column. And then you use sticky notes or cards or whatever you happen to have, but some visual signal that represents units of work that travel through that very high-level process.

I'm going to go deeper though today, and I'm going to talk about some of the origins, and I'm really just going to get started. But then a little later in the episode, I'm going to talk about different levels of Kanban board, the way that you can design Kanban systems so that those levels interact with each other. And as I've talked about a little bit in some of the past few episodes, I will get into why using a true Agile Kanban tool as opposed to just a cards-and-columns interface is really going to get you further with the methodology. It's going to get you further towards your goals and the reasons why you're trying to improve things and adopt these new methods in your practice. So, without further ado, I'm just going to dive in.

The first thing to know in the history lesson, Kanban is a Japanese word. I do not speak Japanese, so everything that I'm telling you is basically as I understand it. But it means card or signal or sometimes sign. And one of the things that someone once said to me is, if you are a solo attorney and you're going to start up a new law practice in Japan, you're going to hang out your shingle, you would be hanging your Kanban. That's your sign, and it's a signal to the world that you have a storefront, have a business, have an offering for the world.

And the reason that we use this Japanese word is that the original use of Kanban in industry came out of Toyota. There's this whole deep thing around the Toyota production system, and I won't get into the history of how Toyota evolved from being in this relatively challenging, well, very challenging post-World War II Japanese economy into becoming one of the biggest businesses, if not at times the biggest auto manufacturer, at least in the world. But the Toyota Way, the Toyota method is really sort of the special sauce that helped get them there.

In the 1980s and the 1990s, I guess I should say now, that is when the Toyota Way sort of jumped out of Toyota and car manufacturing specifically and kind of evolved into the thing that is now known as Lean manufacturing. You may have heard of it as Lean Six Sigma. There's sort of other things as well, and you may have heard of none of these, and that's okay. But to the extent that people have heard of these things, they've usually heard of them as Lean manufacturing.

And one of the problems that Toyota was trying to solve with this lean manufacturing method was to create more smoothness and better predictability in the flow of their product line, right, their manufacturing line. And what they found in the initial going was that different stages of the work proceeded at different paces, and that would wind up causing these little sort of pools of partly finished work all over the factory floor.

So I'll maybe use a bike factory is the one I like to use as my example. So if you imagine at one end of a building, you've basically got the loading dock where the raw materials come in and, you know, we're talking about tubes of metal and we're talking about component parts and, you know, maybe all the different things that go into bicycle manufacturing, plus all of the supplies, like paint or sanding things or welding rods. And they all come in as inventory, and then the bike itself, right, the raw materials for the bike have to be cut, they have to be welded, they have to be sanded, they have to be painted, they have to then have the components installed. And each of those phases in the manufacturing process naturally sort of proceeds at a different rate.

And what they found, right, Toyota found and at this point thousands of, if not tens or hundreds of thousands of manufacturing businesses have found who have adopted these lean methods, is that maybe the cutting station is just a faster overall process than the welding station, which makes perfect sense, right? It's easier to cut something than it is to join it back together. And so what would happen is if the people in charge of the cutting station were incentivized around quantity or around speed, then they would cut all of the tubes or all the other pieces of the bike that needed to be assembled, and then there would be this giant stack of cut pieces in front of the welding station. They would take up space on the floor, they would produce sort of this stress signal for the welders. It was a problem in the overall workflow.

And the thing that the managers, the owners at these manufacturing companies came to realize is that the partly finished work represents an investment that they've made in the product without being able to yield the benefit of actually selling that product. So at this point, they've paid for the raw materials, they've paid for the labor of the cutting, but they can't sell the cut part. It's a partly finished product. And so it's just sitting there as a form of inventory that is not generating any return on investment for the maker, right, for the company. And as in any business, right, we want cash flow, we want return on investment, and we don't mind making investments, but there's time value of money involved. We want the work to pay off as sort of predictably and ultimately as rapidly as possible. But one of the things, and I've talked about this in past episodes too, that they've adopted is this mindset that is best encapsulated from this military phrase, which is slow is smooth and smooth is fast. And this is something that sort of comes up over and over again in a lot of these methodologies.

And the other thing, as you can imagine, is these pools didn't just happen at this one place inside of the factory floor. They happened in a few other places. So it may be that the welding station was slow, but then the paint station was even slower because you've got to like put the parts and let the paint dry. I'm making this up, right? But you can kind of envision a inefficient factory floor where there are relatively large piles of work in lots of places across the factory floor, and those piles of work, again, number one, they represent investment without benefit. Number two, they just take up space. And so, you know, if you're going to work that way, you sort of have to have more capacity in your building, more square footage. On top of that, you have to sort of keep track of these parts, and you have to label, "Oh, this is part A, this is part B, this is part C," and we're doing all this sort of administrative overhead keeping track of this unused inventory or this partly finished inventory. And all of that added expense to the process.

And what the Toyota folks, and again, other Lean manufacturing folks are trying to do is drive expense out of the business as much as possible, right? To get their investment to a substantial return on that investment as smoothly and as ultimately as quickly as possible. And so they came up with this technique to basically say, "Hey, cutting station, we don't want you to cut any more parts than we can reasonably use in a day." And that way, we're going to actually, number one, not have to have as much inventory sitting around.

Number two, it may be that yeah, the cutting station is really fast. Therefore, we can take the labor, the workers who operate that cutting station, and maybe repurpose them or cross-train them or otherwise use that resource at other parts of the factory floor. And in a way, what we're doing is helping to load balance the entire system as a way of smoothing out the flow of work and getting the finished work out the door in that smoother, more predictable way, as opposed to accomplishing the interim step of just cutting lots of pieces that are ultimately going to become a bike, but the pieces themselves don't have inherent value.

And so the question became, how are we going to signal to the cutting station, and really to the factory overall, that, hey, we're starting to run low on these cut pieces that we're going to weld into a bike frame, and we need someone to go staff the cutting station so that we can create some more of the raw materials that we need in order to produce the finished product. And the tool they came up with is what they call a Kanban card.

And again, that's even a little redundant, right? A Kanban which is a card, right? But it's a visual signal. And in this case, it was a physical card that when you got to a certain level of inventory that was like, "Oh, hey, yeah, we can weld a few more bike frames here, but in about 2 or 3 hours, we're going to run out of raw materials, and we don't want to run out of raw materials. We want to produce bikes. So somebody has to go cut some more tubes and get us these raw parts."

And keep in mind, when this was originally invented, we're talking about the 19 late 1940s, early 1950s. So very analog environment. There were, I think, rudimentary computers, but they weren't doing much out in the world. And so they created this physical card, and when supply got down to a certain level, somebody would manually sort of run the card up to the cutting station upstream in the process, and that card would say, "Okay, now you need to cut enough of the raw material tubing so that we can make, I don't know, 20 bike frames or 10 bike frames." Whatever the right number was, it didn't matter. But they were going to really specifically make only a number of these in-progress units that we can reasonably use in a relatively short time period.

And that actually existed throughout the factory floor. And so what you wind up then doing is having this interesting thing where I just described the factory floor through the perspective of the loading dock. And we're basically saying, "Okay, we have these raw materials that come in through the loading dock, and we're going to push them through the factory floor. And at the tail end of it, at the shipping dock, where we're actually pushing things out to our customers or to the retail stores that will sell to customers, however this model works." The idea that I described was pushing work through the factory.

So we have these raw materials, and we have to push them through to create bicycles. But that's actually not how most modern manufacturing floors work today. And instead, what they do is use the series of Kanban signals that start at the shipping dock. They start at the end, the delivery system, where, again, maybe a bike shop has said, "Hey, yeah, I want 10 of these fancy mountain bikes, and I need them in four different colors because I think I can sell them to my customers in Poughkeepsie."

And then that order actually triggers this cascade of Kanban cards that would go further and further upstream. So it's like, okay, well, we need these seats and the derailleurs and the brakes attached. And that's maybe the final step before it gets to the shipping dock. And so there's that station, and then upstream of that, there might be the assembling of the crank and the pedals and all of the other parts. And then upstream from that might be the sanding that comes off of the paint station. And then upstream from that is the paint station, and I won't keep inventing this, but you see where I'm going.

At each stage, the signal to produce work doesn't come from upstream, it comes from downstream. It comes from that order, that actual customer delivery. And so what we have in this factory floor that I'm hopefully describing reasonably well to you is a pull-based system, not a push-based system. We're not generating a lot of work so that we can go store it in warehouses with the hope that someday it will sell. We are responding to actual demand, and we are doing what you may have heard of as just-in-time delivery as close as possible. But we are basically saying we're not going to build a thing until we've know that we've sold that thing. And then we're going to organize our systems using these signals to be able to pull work through our factory floor and meet that order as effectively, as efficiently, as smoothly, and predictably as possible.

And like I said, the whole communication method was through these cards, these visual tangible signals that said, "Hey, there's an order for three red bikes. And therefore, when it gets to the paint station, the paint station knows, "Oh, we've got to go find the red paint, and we got to make sure that we have enough supply of red paint on hand to be able to produce this order of three red bikes." And if we don't, right, and again, we use a Kanban signal in the inventory for the paint, where once it gets to a certain level, and we know historically that we need to produce 100 red bikes a month, whatever, I'm again, I'm making things up, but if the paint gets below a certain number of gallons, then we know we've only got 50 red bikes left. Therefore, we better go order some more red paint because it typically takes about a week and a half for red paint to arrive from our supplier. And therefore, we're pulling that raw material into the system as well. And again, you can kind of imagine it becomes this really intricate web of signals, all of them with this physical tangible representation of the work.

Now, that concept sort of escaped manufacturing. And so there are lots of places in the world where you will see these visual signals that are designed to tell you that we need some more of a supply of something, that we need some more inventory for something. One example I talk about is what I will refer to as industrial Kleenex or sort of work setting or hospitality setting, boxes of Kleenex, where you've probably seen this. You'll be pulling Kleenex or tissues out of the box, and they will be white. And it'll be white, white, white, white, white. And then when there's like 5 or 10 left, they change color.

All of a sudden, they're tan. And what that tan Kleenex is doing is acting as a visual signal to the housekeeping staff or the supply staff, whatever the person is or the team is. And so when a housekeeper is in a hotel room and they're cleaning that room and they glance across the room and they see the box of tissue and they see a tan tissue sticking up out of that box, that's a signal to that housekeeper that you need to swap out that box of tissue with a fresh one. Because if you don't, then you're going to have a new guest in that room who has a little bit of a runny nose and within 25 minutes of arriving into the room, they're going to be calling the front desk saying, "Hey, I'm out of tissue. I need more." And now they're in a sort of a diving catch or they're in a like, "Oh, we have to do something outside of our normal routine in order to deliver this box of tissue," which, you know, they're happy to do. It's hospitality.

But I think you see where I'm going. They don't want to have to deliver this box of tissue on an immediate demand basis. They want to have a system so that they almost never have to do this diving catch or this immediate demand thing around delivering a box of tissue to room 203. It's a way of smoothing out the workflow. It's a way of creating balance and predictability in the supply of tissue paper in, in this case, hotel rooms.

Another place where you've almost certainly seen it in the real world is cash register tape. And so when you've got a cash register and it's printing receipts and you've probably all have had the experience or seen the experience where they ring up your order and they hand you your receipt and all of a sudden there's a pink stripe that is on part of your receipt. And that pink stripe is a Kanban. It is a visual signal to the cashier that you're running low on register tape. And it doesn't mean that you have to immediately replace it, right? But what it does mean is you maybe only have one or two orders left before you're going to have to replace it.

And therefore, you probably want to take a quick break in between customers so that you can replace the tape instead of doing the disruptive thing, which would be, "Oh, I just ran out of tape as this one customer's order was printing or receipt was printing. Therefore, I have to not only stop what I'm doing, replace the tape, now I have to reprint that receipt." And that's probably a whole complicated series of keystrokes, or maybe you got to go get the manager with the special key. Whatever it is, that's a really disruptive process.

Running out of tape in the middle of something would suck. So instead, we give them a warning and they know that, "Okay, I'm going to take 25 seconds in between these two customers in order to replace the tape, as opposed to creating this disruptive thing where now I have what I've talked about before as failure demand or something is broken. I have to fix it. I have to rework. I have to go through this process again, which is inefficient in the overall workflow of grocery store checkout."
So that's a system, right? This use of Kanbans is something that's been around for, gosh, 70 plus years now. I think it probably has been mainstream since the 1980s, 1990s, early 2000s in all sorts of settings. It's really popular in healthcare around medical supplies. It's obviously in all sorts of industries, grocery manufacturing, etc.

But then we get to this interesting thing in the late 90s, early 2000s, where this notion of using Kanban signals around inventory made this sort of logical leap into software development and computer programming. And this is where it gets really interesting for nerds like me, at least, and hopefully you're still with me here. And this is ultimately where we wound up with the increasingly popular use of Kanban boards in legal, which is it started in computer programming.

And instead of just signaling inventory, although it does still in a way signal inventory, the Kanban card kind of morphed to become this physical, tangible, visual representation of knowledge work, of work that is otherwise hard to see because it tends to exist on our devices or between our ears, and it doesn't have this sort of tangible physical form that the manufacturing world does or that the retail world does because you're literally moving inventory around.

You can see it, you can see when it builds up, you can see when things get stuck, you can feel when it's not working properly, and the human brain, the human condition is really well adapted to responding to all of these visual physical signals, but it was harder in knowledge work, right? Lots and lots and lots of knowledge work can build up in a computer or even build up in your head, but you don't feel the weight of it. You don't see the size of it.

And so the original sort of inventors of what became this agile set of methodologies started to use a Kanban style system to represent knowledge work as it flows through a process. And as I said at the top of this episode, the work itself started to get represented by the Kanban cards. So the cards aren't necessarily signaling just the need for inventory anymore, they're signaling the work itself. Instead of a bicycle, a particular function inside of a computer software is represented by this physical card. And originally, it was physical.

So the early Kanban boards were usually 3x5 index cards on a cork board or a magnet wall, and then eventually started using, a lot of teams started using sticky notes, although there were debates about people that loved the old 3x5 cards or sometimes they'd use 4x6 cards. There's lots of ways to do it, right? But these tangible representations of work, and then they would use columns on these walls, on these boards to represent stages of work.

In the software programming world, the stages, typical stages would be things like maybe a little bit of research at the very front end, and then there would be the actual coding or development, and there'd be a column for that. And then there would be a quality assurance step, which is to make sure that the code is actually, number one, doing what it's supposed to do, and number two, not breaking other parts of the software. And then there might be a user acceptance stage. And every new function, every new bit of computer software would flow through these predictable stages represented by cards on this board.

And in doing so, it basically took this otherwise invisible knowledge work and made it visible, it made it tangible. And in that way, it allowed software teams to begin to operate more like a factory floor. And again, by this time, Lean manufacturing was already pretty well established. We had created, we, society, humanity, had come up with some really effective tools to make manufacturing work better. And the original Kanban boards were, in the software industry, were the beginning of a process that allowed us to do the same thing again, initially in software development, but really, ultimately in all forms of knowledge work.

And this is where you get into my weird background because I started my career in technology in the mid-90s. I did not go straight to law school out of undergrad, and I actually worked at a company that was called Photodisc. We quickly merged with Getty Images. And even though you probably think of Getty Images as a photography company, and it is, it delivers photographs, really, it's a software company because the work that we were doing at the time was to figure out how to create software systems and web-based software systems specifically that allowed people to browse a catalog of photographs, find the one that was right for their use, and then purchase that photograph, get it delivered to them in a high-res way so that they could then use it in whatever project they needed to use it in. So we're looking at this process of how to catalog and then let people purchase and then deliver this digital product in a way that moved as smoothly and efficiently and intuitively as possible. And we used software to do that.

And I was lucky enough to have this interesting sort of two-part interaction with Getty Images where when I originally worked for Getty in the late 90s, early 2000s, we were doing things that I think of as sort of proto-Agile. So they were using techniques, the software team was using techniques that eventually kind of coalesced into what we now think of as the Agile methodology, but we didn't have a name for it at the time. They were just sort of practices that people were trying out, and they worked pretty well. But we also didn't have necessarily a coherent approach to it. And in terms of how we managed the actual technology projects, we used a very traditional, what's now called Waterfall version of project management. And I won't go too deep into the difference between Waterfall and Agile, but it was an older way, a more classic way of working.

But then, you know, I got this wild hair. I wound up going to law school, and I came out of law school and my very first job out of law school was back at Getty Images as a junior in-house counsel. And while I was learning how to do the legal work, right, I still had a lot of colleagues, a lot of friends who were in the company that had been there the whole time I was gone. And while I was away in law school, Getty switched from being a traditional project management shop to an Agile shop. And I got this really interesting before and after of how much more effective the delivery of new software functions, new features was under these Agile methods versus even the proto-Agile things that we were doing before I went off to law school.

And again, in terms of my origin story, this is where I had the seemingly crazy idea that, "Oh, I wonder if this could work for lawyers." And, you know, this is probably 2007, 2008 timeframe. It took me a number of years to get to where I actually started poking at that because, like I said, I was learning how to be a lawyer. I wasn't necessarily at the place where I needed to worry about case flow or matter flow, but obviously that idea stuck with me and sticks with me to this day.

I think I'm actually going to break this episode now. I was originally going to try to do a long episode that gets into Agile Kanban, but I went a little deeper on the Lean thing, and I actually think there's some important takeaways for lawyers from even that physical world, that Lean version of Kanban that you can use to think about your own law systems and legal product delivery systems better.
And I'll start with that thing I just said, right? I've got this funny lens where I think of legal work as products, as a series of products. And yes, legal is a service industry, and yes, we are providing services to our clients, but we're providing those services through the form of tangible outcomes along the way. And I really like those outcomes to be physical or at least visually tangible as we go. And so one of the lessons of Lean Kanban is that visual systems are really important and that visual signals convey information in a way that is far more powerful than words or lists of things or other ways of communicating.

And so one of the things I talk about with my clients all the time is, "What is your tangible manifestation of value?" Right? Okay, you just did maybe a new client consult or a client intake meeting, and you conveyed all kinds of information orally to the client. And the client maybe felt really good about that interaction in the 10 minutes after it was over. But almost immediately, that information that client obtained starts to degrade. I sometimes say that oral information has a half-life, and the amount of detail that people retain, the amount of information they retain starts to degrade, and that degradation gets stronger and stronger over time.

And I'll give you the place where you may have experienced this, right? If you do a client meeting or deliver some unit of value at the beginning of the month, but then you don't send your bill until the end of the month, the feeling of value that the client has had from that unit of work has degraded substantially by the time your bill arrives. Again, assuming you're an hourly biller, which most of you probably still are. But if you take this other approach, if you say, "Okay, great, we just had this intake meeting, and I'm going to send you a document. I'm going to send you even just an email, but I think it can be better if it's something a little bit more designed, a little bit more whatever, but I'll start with minimum viable product, right?

It can be just an email that says, "Hey, great talking with you. Just to reiterate, here are the five things we discussed. Here are the three things you need to do, and then here are the other three things I'm going to do once I get that from you." That is a tangible manifestation of value, and it creates a little bit of a visual signal. Again, email's not my favorite because it's easy to get lost in the morass of other emails. But something that the client can point to and say, "Oh, yeah, that's the value I got. That's what I learned. Here's a thing that I can refer back to in order to recapture the value that was delivered in that meeting originally."

So lesson one from Lean Kanban is just the power of having there be sort of this visual, tangible thing that represents the work or the inventory or the need for work and that the client can hold on to.
The second thing I want you to take away from this Lean example is the problem of having part-finished work clogging up parts of your system. And the place where I see this the most in law practices is kind of the same as the example I gave with this hypothetical bike factory, is with the very first parts of a law matter, a legal matter, right? We love to do intake. We love to get cases started. But we do it sort of without an honest acknowledgement of our overall capacity about how and when we're going to actually deliver that finished product.

I know that law processes are complex. I know that we can't accurately predict, you know, especially with things like litigation or complex mergers, whatever it happens to be, there's lots of things that it's hard to know end to end that we're going to be able to produce a bicycle in X amount of time because it's not that predictable. There's too many other factors. You're dealing with opposing parties and opposing counsels and judges and all of the myriad ways at which work can get stuck or stalled inside of your system. So I get that's a problem, but we should be working towards that ideal even with all of the variability, even with all of the outside dependencies.

And so to say it more explicitly, just like we don't want that bike factory creating a lot of part-finished work without a plan for how that work is going to actually get out the door of the shipping dock and delivered to the retailer, the customer, whoever it is that ordered those bikes, I don't want you to be taking work into your law practice on this push basis where we're saying, "Oh, well, there's demand, and I can sign them up, and so I should just bring them into my system, and I'm going to push the work in, and then we'll just sort it all out. And we'll kind of figure it out as it goes and we'll deliver work as we can deliver work." It's a really common way for law practice to operate, and it is a recipe for disaster. It is the reason you have overwhelm and overload and overburden in your law practice.

And so, just like a factory floor, its carrying capacity is limited by the square footage of the floor space inside of the factory. And so if they were to have too much unfinished work, eventually it will overwhelm the system because there'll just be this whip everywhere, this work in progress that is making it hard to see things, making it hard to move around, creating all this extra work around tracking and inventory and management and communication about what are we going to do with all this WIP, none of which is actually generating value for your client, right? It's just gumming up the works.

And so, like a bike factory shouldn't sort of start work on a new bike until they have a reasonable articulation of a plan around how they're going to deliver that bike and when, I don't want you to take new work into your law practice unless you can articulate a reasonable plan for how that work is going to get finished, how it's going to get done. And there's lots of things I talk about the honest reckoning with capacity all the time. We want to get to a sense of what is the carrying capacity of my law practice.

The third and the last takeaway I'll give you for now is the importance of using a pull-based system in order to work within that capacity. And so instead of, as I said, just taking work because it's available or doing intake and incentivizing my intake team on a volume-based goal where their job and their bonus and their benefits and everything come from, "Oh, I converted a certain number of people and got them in the door." That is a what we call in lean manufacturing a local optimum, and those local optimums are suboptimal.

If we were to incentivize the cutting station for all of the inventory they create, even though those raw materials are just stacking up in front of the welding station, we don't want to incentivize your intake team or your marketing team to bring in more work than your firm can comfortably handle because that work is just going to start building up and it's going to cause problems. So what we want instead is to instead of this push-based system where we're taking work because there's demand, we're doing a pull-based system, which is where we are committing to small units of demand based on our capacity.

All right, I'm going to leave it there for now. If you want to go a little deeper on lean, there's actually a really interesting This American Life episode about the NUMMI plant and the history of the NUMMI plant. I'll put a link to that in the show notes. But for now, if you have any specific questions about how these concepts, which I obviously geek out about, can apply in your law practice, or, you know, obviously getting into any of the deeper methodologies around the Kanban method, Agile in general, and how we can start using these tools to not just make things calmer and more predictable, but ultimately make more money, deliver more work through your practice because we're not gumming up the system, we've got smooth predictable flow, reach out to me, right?john.grant@agileattorney.com. You can find all kinds of information on the website at agileattorney.com.

I will also continue to tease the software tool that I am building with some co-founders right now. We've got our landing page up at greenline.legal. This is going to be, I think, the only software tool that really uses the methodologies and the deep knowledge around Lean and Agile methods to help support more effective practices in law firms and other legal teams. So I'm really excited about it. It's still is going to be maybe a few months before it's ready for prime time. But if you go to greenline.legal, number one, I'd love to get feedback on what you think of the landing page and the way we're trying to sort of position this product so far. But also, you can sign up to get notified and maybe be part of the initial cohort of folks that is using this software tool that is a truly sort of purpose-built system using these deeper methodologies, deeper philosophies for law practice.

All right. This podcast gets production support from the amazing team at Digital Freedom Productions, and our theme music is "Hello" by Lunara. Thanks for listening, and I will catch you next week.