Podcast Ep #77: The BEST System for Managing Legal Work: Kanban for Lawyers Part 3

For the past two weeks, I've been talking about some of the predecessors to the Kanban method, Lean from manufacturing and Scrum from software development. And I've shared specific techniques you can take from each to improve your legal practice. But neither of them is quite right for managing the unique needs of a law practice overall. Most legal teams operate in an extreme multi-project environment with long cycle times, lots of external dependencies, and constant context switching. And that's different from what you see on a factory floor or with a software team.

It's also where the Kanban method really shines. And I'm talking about the full method, not just using a Kanban board. In today's episode, I'll show you why Kanban is the most practical and powerful system for managing legal work. And I'll start to introduce some beyond-the-basics concepts that help make it so powerful.

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. So this is going to be part three and the last part of a mini-series that I've been doing on sort of the origins of the Kanban method and ultimately why I think this is the method that is the best one for most lawyers and legal teams in most situations. It's not the perfect method for all situations, but it really does, I think, hit on most of the challenges and the issues that we face as lawyers and provide some really good tools and solutions to solving those problems.

And just as a very brief recap, two weeks ago in episode 75, we talked about Lean and Lean manufacturing, which is sort of the origin of a lot of the concepts, but it was really well tailored for things that happen in a physical environment, the factory floor.

Then last week I talked about Scrum, and that was really the first sort of methodology out of the overall Agile umbrella to make a big impact on the world in general, but it was really specific to the needs of software teams. And again, there are a lot of things from Scrum that we can use in other knowledge work environments, but there also are some unique needs of software teams and some aspects of software teams that aren't necessarily the same as what's going on for most legal teams or in most law firms.
And one of the things about Scrum in particular is that it is really geared towards new product development or bringing new ideas into an existing product. And it's very much built around this idea that there are a lot of unknowns that we're trying to discover through this iterative process. And there are elements of law practice that are like that as well.

But the thing about Scrum and Scrum teams is that they tend to be really focused on a particular product. And sometimes with bigger companies, not just a product. Sometimes you'll have a Scrum team that is dedicated to even a really narrow feature inside of a product, right? Maybe the new music recommendation inside of Spotify, something like that. And there'll be teams that are really just hyper-focused on that problem for months and months or even years, and they're constantly iterating on that one thing.

And one of the knocks on the Scrum methodology, people that have been practicing it or around teams that use it, is that it begins to struggle in multi-project environments. So it's great if you can dedicate a single team to a single set of problems or a single product and iterate it over time. But if all of a sudden the people on that team have to be involved in a couple of projects or supporting a few different features, then it can be hard to coordinate work across those multiple projects.

And the thing that I eventually realized talking with Scrum folks and trying to adapt these things into the legal world. And it's kind of funny because when software folks talk about multi-project environments, they're talking about two or three or maybe like five projects. And legal is nothing if not an extreme multi-project environment, right? We've got these situations where for most firms, most of the time, you're handling dozens, if not hundreds of open cases, depending on your practice area at a time. And Scrum really struggles in those types of situations.

Now, I will say if you're in a big firm or maybe even on an in-house team and you do sort of have these bigger, longer-term projects, right? Complex litigation, a massive merger and acquisition deal, something like that, then Scrum actually can work really well. So I'm not saying that Scrum never works in legal. There are definitely situations when you can have a dedicated set of resources, even if you're pulling in other people on occasion, but if there's a small group of folks focused on really one big case or one big transaction, then Scrum can be a great way to organize that. But I think that's the minority for most of you in law practice, right? We don't have the luxury of being able to monotask like that. We have to juggle all of these different client matters and we do all this context switching, and Scrum isn't really set up to support that.

And it turns out that there are situations like we have in legal that exist in technology teams too. And so the sort of genesis of the modern Kanban method, and as I've said before, I wish there were a better term. I wish they'd named it something other than the Kanban method, frankly, because Kanban boards and the word Kanban is an imprecise term because Kanban exists in Lean and it means something there. Kanban boards exist in Scrum and they mean something there.

And now we've got this whole methodology that we're building around the term Kanban and it's confusing, but we're kind of stuck with it. I'm actually working with some folks, Tim Lennon, who I've had on the podcast a couple of times is one of them, to maybe take some of the jargon out of these methods and figure out ways to present them using language and examples that resonate with everybody and aren't reliant on all these funny words. But that's something we're working on. So for now we're stuck with the term Kanban.

But the modern Kanban method, which also emerged out of the software industry, but it emerged out of a different part of software teams, and it was mostly these teams that were supporting things like bugs or user feedback or sometimes help desks where there was a steady supply of new work coming in, either bug reports or customer questions, things like that, that the team needed to handle a volume of requests, right? Things that were needed their finite time and attention, but then they had a relatively stable process for addressing those requests.

So again, instead of building and discovering and figuring things out and doing these testings and fast feedback loops, all of which are important in certain situations, it's a little bit more like a factory floor where you have an order for a widget and then you have to gather the raw materials and put them through a process and people have skills and training and tools that they use to assemble that widget. And the Kanban method was this way of applying what the software teams learned from Scrum, which was great. There were some really good breakthroughs, but then settling it back in a more fit-for-purpose way that solved these other problems inside of the team.

And the way that it does this, right, it begins with a Kanban board like in Scrum. And as I talked about last week, the beauty of the Kanban board is it is a visual fiction. It allows us to visualize the work as it flows through a knowledge worker process. And it's actually visualizing two different things, at least two different things.

One of them is the process through which the work has to travel, and those are the columns on the board. So for most legal processes, we begin with an intake phase, then we might move into something of a research or maybe a strategy phase. And then it diverges depending on your practice area, whether you're litigation or transactional, things like that. But ultimately, there's going to be the delivery of some work and maybe there's going to be delivery at multiple stages along the way.

In fact, usually there is. But we've got columns on the board set up to represent what are those stages, what is the deliverable that needs to come out of those stages, and then eventually we build it to a finished product. And whether that, again, is an outcome in a litigation or maybe a divorce or an immigration case in the case of more of an administrative processing, or it could be a transaction, right? We've registered all the things that you need to do to achieve this particular piece of intellectual property protection or business registration, things like that.

Then the other visualization we have is the cards on the board, and the cards represent units of work. And the most common setup, although I'll talk about some other setups in a minute, the most common setup is for the unit of work to be the matter, right? Whatever the case is or the matter is, that's what's flowing through these column stages in order to get to whatever done looks like for that stage or for that matter.

Now, once we do that, then we've got this beautiful thing where the Kanban board serves as this sort of map that allows you to see work in your system much like if you had crawled up into the catwalk or the rafters of a factory and were looking down on the factory floor. You can see the different stages and you can see how much work is built up at each of those stages.

And that's where the magic really starts to happen. And actually, I should say, even before that, the thing I hear more than anything from people that are first adopting these Kanban boards is the visual nature of their caseload is really impactful for them. One of the things I hear from folks a lot when they're first reaching out to me or even just exploring out in the world is, "I'm having a hard time managing all of my work. I'm worried that something is going to fall through the cracks. I'm worried that I'm going to miss an important deadline, an important thing, a communication, whatever." And there's something about being able to see all of these cards that represent your work and where they all are that just sort of helps your brain make better sense of what's going on in the practice overall.

Now, the other thing that jumps off the screen, the page, the wall, whatever sort of Kanban boards you're using, is that it also is really good at showing you where the bottlenecks are. It is immediately apparent where work is getting stuck in your system. And just like I talked about in episode 75, in this hypothetical bike factory, if the folks that are cutting the raw materials, right, the metal tubing, whatever, are working faster than the station that can reassemble them and do the welding to get them into a bike frame, you're going to see lots and lots of part-finished work stack up somewhere in that welding station.

With legal, the situation that I usually run into is that the sales and marketing and intake team are outperforming the firm's ability to deliver work. And it's not always a separate team, right? It's sometimes just the function, and people will organize their law practice to overemphasize the getting the work functions, the biz dev functions, and then that work winds up getting stuck somewhere else in the process, somewhere in the delivery workflow. And I did a really deep dive on bottleneck theory all the way back in episode three. I think it's still a really good episode, so I won't go too far down that rabbit hole now.

But I will say there are two bottlenecks that almost always emerge, and one of them has to be the worst, but there are almost always two sticking points inside of a law practice. One of them is client homework. And especially for those of you with transactional practices, although this comes up in litigation practices too, you can't do your thing accurately until you have the information and materials you need from the client. So one of the things that I am always working on with my law firm clients is what can we do to more actively manage client homework, not engage in the fence-chucking that can happen where we just make a homework assignment to the client, assume that they're going to do it, and then get frustrated with them when they don't.
And I've done several episodes where I talk about this client homework bottleneck, but the one that I really keyed in on it was episode seven. So again, sort of back towards the beginning of the podcast, but it comes up over and over again.

The other bottleneck that I see is senior attorney review. So people on the team, whether it's legal assistants, paralegals, associates, whoever, have done a chunk of work, they've drafted a document or they've produced a memo, whatever it happens to be, but it needs to get reviewed by the senior attorney or partner, whoever. And often that's you, I think for most of you who are listening to this. And work gets stuck at that review stage.

And I've got a great episode on this as well. It's episode 36, What to Do When I'm the Bottleneck, where I talk with Ben Hudson about his realization that he is in fact the bottleneck in his law practice and that he needs to be more intentional about, number one, where he spends his time and activity to ensure that work isn't getting stuck at that review stage. But then even further, how can he manage the upstream work and the assignments to his associate, his paralegal, so that the work is only coming into his review stage at a rate that he can handle.

And basically, what we're doing here is we're applying principles from Lean manufacturing to the knowledge work environment that is law practice. And it works really well. And this is where a couple of the other practices of the Kanban method come into play. There's six of them total. I won't go through all of them, but there are three main ones. One of them, which again is really akin to Lean manufacturing, is to limit the total amount of work in progress that is happening inside of the law practice. We establish these WIP limits to make sure that we are only bringing as much work into the system as the system can reliably and predictably handle.

Now, I will admit, this is the biggest challenge I have with the law firms and legal teams that I work with is they are existing in a world where demand is really, really high relative to their capacity, and it's super easy to overcommit, to bring on too much work. And again, as I've talked about over and over again, it's the fact that there is so much work in your system that is causing all of these knock-on problems inside of your system.

And using these WIP limits, right, setting these maximums, and they're theoretical maximums, it's not usually a hard and fast rule, but being able to gauge how much can we handle, both at a practice-wide level, although that's the harder one, usually we'll begin by setting WIP limits at individual stages. And there's two ways that we do this. One is certainly for the working stages, we want to make sure, and let's say it's a drafting stage, we don't want to have too many drafting projects in flight at once, right? For the team, for individuals, whatever sort of unit of capacity we're talking about, it makes no sense to be actively working on five different pleadings at the same time.

It's far better to say, "I'm going to work on this one pleading. I'm going to get it all the way to done. I'm going to get it to the next stage where it can be reviewed and eventually filed and served, and we can kick this darn thing off," as opposed to working a little bit on pleading A and then putting it aside and then working a little bit on pleading B and then putting it aside, etc., etc. on through G and H maybe. And then we've got all of this in-progress work, none of it actually usable until we get it across the finish line for that stage.

And so we might put a WIP limit on that drafting stage, say we're only going to be working on one thing at a time. Ideally, that's not always realistic, but maybe two or three, maybe even four or five, whatever it is, we're going to cap it. And eventually, when that sixth one shows up and needs work, we're going to say, "Nope, you have to wait. We have to deliver at least one of these, ideally all four or five of the ones that are in queue ahead of them." But we have to deliver at least one before we begin work on the next one.

And that sort of gives you the next state or the next phase of this implementing WIP limits, which is once you have that one unit that is going to exceed the WIP limit, you have to hold it somewhere. And so the other thing that we wind up doing is creating these express queue columns or waiting columns where it says, "Oh, we can't begin this pleading yet. We have to park it somewhere." So we're going to park it in a queue. And this is the second place where WIP limits will eventually come up. Usually at first, I don't worry about setting WIP limits on the queues, just let stuff build up there. But over time, if the queues get too long, then we have to start putting WIP limits on them too. And I've done a deep dive episode on WIP limits as well. That's episode 56, so you can go back and check that one out.

Now, the next practice of the Kanban method is to make policies explicit. And that's another one of those terms that comes from this methodology that I think is a funny one. What we mean by this is create some quality standards, some rules, some policies and procedures, and make sure they're written down and they're visible and they're understandable and they're communicated so that we're all working off of the same playbook inside of a practice.

And I'm going to go over my two favorite types of policies really quickly, and again, I've got some deep dive episodes, episode 10, which is titled Make Policies Explicit, and then episode 22, which is about how to write effective law firm policies. But far and away, the two most important policies inside of a law practice workflow, and you need these for almost every stage of your workflow, are these bookends. And the first one is what we call the definition of done. And the definition of done is a quality standard, right? It's a policy that says these are all of the things that need to be true or at least accounted for in order for us to consider this particular matter, this particular deliverable done at this phase.

So, since I've been talking about a pleading example, we would want to have a definition of done for drafting pleadings. And that might have some rules about what is in the content of the pleading document. It will probably have some rules around the format of the pleading document, the caption and the signature line, things like that. It will probably say something about the ancillary documents that need to be drafted alongside of a pleading, right? The certificates of service or various notices, disclosures, whatever your case or jurisdiction requires. And then it might say something about the practices that need to happen for each of those documents, the spell check, the grammar check, checking citations now in this world of AI-assisted editing.

But by coming up with a clear definition of done, and ideally a short one, right? I usually like a definition of done to be somewhere between three and eight items. They can get a little longer sometimes, but we're not talking about the full laundry list. It's not a task list, right? It's not all the things that you need to do. It's the higher-level quality check that makes sure that these are the things that have been accounted for.

And that definition of done is really useful in a couple of places. Number one, for the quality assurance work, right? When the senior attorney is doing review, they want to be able to look and see, "Yeah, the pleading has the right content, it has the right format, it has the right ancillary documents, etc." But it also is really useful in the delivery phase, right? For whoever is doing that drafting, if they know what the reviewer is going to be reviewing against, what is the quality standard that I'm being held to, then they're more likely to draft to that standard.

So, definitions of done, super important, really helpful for making sure that we're producing work in a quality way, in a smooth and consistent way. And the nice thing about a definition of done is it helps prevent rework, right? It means that if you draft and deliver to the standard, then it's likely to not fail quality assurance, which means that it's likely to not have to come back to you to work on again, or if you're that person doing the quality review, it means that you don't either have to send it back or you don't have to clean it up yourself. You don't have to do rework on something that should have been done right the first time, right? And I've talked in the past about failure demand. That rework is a form of failure demand.

Now, the other standard that helps protect against rework is this other policy that we call the definition of ready, right? And this is something that's similar, but it's what are all of the things that need to be true or at least accounted for before we will even begin work on this phase, before we will commit our finite time, attention, and resources to building a thing. Because if you want to go start drafting that pleading before you have all the information from the client or before you've done the research on the case law or the statute or whatever so you don't know what you're pleading against, then the likelihood of you having to open that work back up and redo it based on some new information that comes in is really, really high.

And so, the purpose of the definition of ready is to help prevent you from jumping the gun and from getting too deep into a project before it's actually ready for your work. And I'll often use a cooking metaphor for this, right? If you're going to go cook a recipe, you don't want to begin the process of cooking until you know that you've got all of the ingredients on hand for that recipe, right? It can be really messy or you can even destroy a dish if you have to stop partway through, turn off the stove, and go to the grocery store because you're missing something, right? We want to make sure that we have everything in place before we begin because it helps prevent quality standards with the end product once we actually start doing the work. It also obviously makes the delivery way more efficient, right? If you've got to stop and put it down, then when you pick it back up again, it's going to take longer for you to sort of reboot your brain or people on your team to reboot their brains around what was going on with this. And it's that inefficiency that we're trying to drive out of the systems.

Now, the third of these practices, and I'm going to talk about this one really briefly because I've got some other resources for it that I'll point you to, but we want to measure and manage for the flow of work through our system, not just the effort we put into the work. So law firms are really good at measuring effort. Those are the hours we track, but what we're less good at is making sure that the work itself is moving forward, is making progress. And so we want to put in place some explicit effort to measure how well is work moving through the stages of our system.

And I actually talk about flow efficiency and measuring for flow in that same episode 56 where I talk about WIP limits. I also have a pretty good resource called the Agile Attorney Bootcamp. It is an email course that you can get if you go to register at community.agileattorney.com. And if you sign up for the community, you'll be able to find the link for that bootcamp. So those are a few of the ways in which legal workflows are like, sort of again, both a little bit like what happens inside of technology teams, but also what happens inside of manufacturing teams.

There's one big difference or set of differences that happens in legal that are uncommon in those two environments. And frankly, these are the things that I think help the Kanban method specifically really shine for legal work. And that's external dependencies. I probably need to do a deeper dive episode just on this, but what I'm talking about are, in a manufacturing process, there aren't that many external dependencies. Sometimes you might have some issues getting raw materials, getting tools, things like that. Those are all external dependencies. But for the most part, once the work has begun inside of a factory floor, the factory kind of has everything they need in order to move it all the way through to done, to deliver the actual widget, whatever it is that they're building.

Same is true in a software team, right? There isn't usually a lot of outside information that needs to get brought in order to code a feature or develop a product, right? It's all sort of stuff that exists within the team. But with legal, we've got all kinds of external dependencies. One of them is client review, client homework, the different places in which, yes, the client is ultimately the customer of your legal process, but they are also a member of the project delivery team. And they're not just a member of the team, they're a member of the team that often has multiple roles. Sometimes they're a supplier of documents or information, sometimes they are in a quality review role where you're making sure that the thing that you wrote actually is consistent with their understanding of what's going on or supports their needs, whatever it happens to be. And so managing that particular external dependency is a whole discipline and art and science in and of itself.

And that's just one of many types of external dependencies that comes up, right? Sometimes we have third-party witnesses or experts or providers, right? If you're in a transactional practice, you might need appraisers or accountants or other things that are providing their expertise and we have to manage those outside dependencies. Oftentimes, we have an opposing party or an opposing counsel or both, of course, where we can only do so much in our work and then we have to push it over to their side of the net, and now they have to do a thing and there's not much we can do until they're finished with their particular part of the process and send it back to us, whether that's reviewing things in a transactional setting or hitting their next shot in a litigation workflow.

And then, of course, there are the agencies or the adjudicators or the courts where, you know, sometimes we do a whole chunk of work and we have to push it to them and then we can't continue until they're done with their piece of work. And I put those things in sort of an intentional order because there are things where we have both influence and control, right? And that's sort of our own internal workflows. Then there are things over which we have sort of diminishing influence, right? And our clients, we have a little bit more influence than we do over maybe opposing party or opposing counsel, but we have maybe more ability to influence those people than we do the agencies of the courts where it's just going to take what it takes. There's not much we can do to speed it up.

And this is where a really well-designed Kanban system can shine because we can do things in the board design and the card design and, you know, there are other things, depending on what tool you're using. And this is why I really like tools that are built around the full Kanban methodology as opposed to tools that are just using sort of a cards and columns interface, because with these more advanced tools, we can do things with board design, we can set up tokens or stickers that get applied to cards, we can use a technique called blocking and we can define different types of blockers that lets us know, hey, yes, this is something we have to keep track of, but it tells us how much time and attention we need to give to it, because if it's out with the court, if it's out with the IRS, if it's out with an agency, there's probably not a lot we can do to speed it up. We're just tracking.

If it's out with the opposing party or opposing counsel, maybe we're going to ping them after a couple of weeks and say, "Hey, what's going on? Is there anything we can do to move this forward?" And then if it's out with the client, maybe we can more actively manage it. We can schedule some meetings, we can set up some sessions to try to get them to speed up their work.

Ultimately, what all of these things help us to do is make an educated decision about how we should be spending our finite time and attention across all of the work in our law practice, right? When should we be following up with an external dependency versus beginning to draft new work?
Is it the same resource that does those things? Maybe yes, maybe no. Maybe we engage in some cross-training across the different people and resources inside of the practice so that different people can address different phases of work where bottlenecks might be forming, and that way we can load balance across the practice and make sure that, again, we are all making informed decisions about how to spend our capacity in ways that are going to optimize or maximize the flow of work through our practice and not just the busyness of the people inside of our team.

Now, there's one other advantage to using a Kanban-specific tool, and I'm really just going to bounce off the top of it because this episode is already a little longer than I meant for it to be. But that's the ability to manage work at sort of multiple levels of flow. So what I mean by that is you can set up a Kanban board, and for most people, I think this is the right thing to do, is to set up a Kanban board to manage the flow of matters as they progress through the stages of your particular practice area. But matters tend to be sort of a slow flow mechanism for tracking, right? Most of them take on the order of months. You know, maybe some are weeks, but for most of you, I think they take at least a month or two, sometimes many months, sometimes years. When we're tracking matter level flow, the things aren't moving all that quickly.

But when we talk about the resources on your team, the people, then most of their day is set up around executing certain deliverables, right? Those documents, those pleadings, those contracts, whatever it happens to be. And those specific deliverables are something we want to be flowing much, much faster, right? On the order of hours, maybe days, hopefully not much more than weeks, right? When we're working on a drafting project, we want it to flow smoothly and predictably, but ultimately quickly through our system so that we can deliver this one thing and then put it where it needs to be, right? Get to the next natural resting state, whatever that happens to be, and then we can turn our attention to building deliverables for another matter or for another purpose.

And the problem with a lot of Kanban-based systems, right? Systems that are using this visual metaphor, if we're talking about the ones that are built around law practice management, they are often really good at managing flow, not really good, but they're good enough at managing flow at the matter level. And this is your Cleo matter stages, this is your Legal Boards, this is your Lawmatics, this is your Locus. We're tracking the matter as it flows, but then at that deliverable level, we're back to using checklists. And the problem with checklists is now we're back to a less visible environment. It's harder to see what's done, what's not done, what's in progress, and it's really easy to get into a place of overwhelm at that task and deliverable level, not just at the matter level.

And so the cool thing with these more advanced tools is you can actually create more than one board and you can design it to work at different flow levels, and then you can also connect the cards and the workflows between your slow flow board, your matter level board, and your fast flow board, your deliverables board. And so the way that might work is when a matter card gets to a pleading stage on the matter flow board, then it's going to kick off a child card that is going to exist in a different place. And sometimes that's on the same screen, sometimes that's in a different screen. It's definitely a different workflow where we're going to manage the work for that deliverable or that package of deliverables, right? The pleading and all the ancillary documents that go with it, or the estate plan and the powers of attorney and all the things that go with it.

So now you're managing different levels of flow. We sometimes call them flight levels in the Kanban world, but again, that's sort of an abstract term. But basically, we're able to zoom out and see where everything sits inside of our practice at a matter level, right? We're up on the catwalk in the factory floor. But then we're also able to zoom in using this faster flow board, this deliverables board, and see where are we in terms of progress against particular tasks. And that allows us to arrange, again, our finite resources, our finite capacity to elevate and to work on and to make sure that we deliver the individual tasks that are most important for us to deliver right now.

And I want to emphasize, this is a little bit of a advanced technique or at least a mid-level technique. So I wouldn't necessarily recommend going straight to this sort of split structure, but once you get really comfortable seeing your work at that matter level, then it's probably time to begin looking at building a faster flow board, a deliverables board that integrates with your matter level board so that we can really start to be super intentional and way more intelligent about the delivery systems within the practice.

All right, I'm going to leave it at that for now. Next week, I've got an interview episode where I'm really excited to have a discussion with Danielle Hendon. She is an outside CFO for small and mid-sized law practices. And we dive into a discussion around what she does and what sort of things she's looking for. This is not an accountant. This is a CFO. She's really looking to help you use the financial numbers in your practice to be able to better tell the story of your practice and achieve the goals that you're trying to get to. So you're not going to want to miss that.

As always, if you have any thoughts or questions or topics you'd like to hear me cover, you can reach out to me at john.grant@agileattorney.com. You can also contact me through my website. As always, this podcast gets production support from the fantastic team at Digital Freedom Productions, and our theme music is Hello by Lunara. Thanks for listening, and I'll catch you next week.