How lawyers can use Agile project management and kanban

One of my core beliefs in managing our law firm is that we should borrow ideas from businesses outside the legal field. Attorneys are notoriously slow to adopt new ideas. While the rest of the world rushes by with creative new ways of getting things done, law firms are too often left behind. A prime example of that is in project management, which is a discipline unto itself. Whether attorneys chose to realize it or not, we are all professional project managers. Regardless of our practice area, lawyers are hired to get a project done. We are not paid to be smart, we are not paid "for our time" - we're paid to accomplish goals. Obviously accomplishing those goals is largely what legal education - and legal experience - is all about. But in addition to our training in the law, its extremely helpful to recognize that there are smart people out there who for the better part of a century have thought about project management as its own discipline. Growing largely out of the Toyota manufacturing revolution, the most commonly deployed project management techniques grew of age in the software development and high-tech fields. This post, which coincides with a couple talks to a section of the King County Bar Association, is a brief overview of how attorneys might benefit from the project management approach known as Agile.

The 50 Shades of Grey Teddy Bear

Let's begin at the natural starting point for legal project management: the 50 Shades of Grey Teddy Bear. First of all, yes this is a thing, and no this is not an affiliate link.

Fifty Shades of Grey Movie® - Teddy Bear

I was introduced to the Teddy Bear by my sister, Kay, who works primarily on organic farms. But since organic greens - like other greens - tend not to grow in the winter, she and her colleagues tend to look for alternate jobs, including in small manufacturing. Close to Kay's farm in Vermont there was a small facility that packaged these - ahem - Teddy Bears. While I don't know if this is still true, at least during the last Valentine's season it was possible not only to order one of these Teddy Bears for your loved one, but also to include a note of the character befitting an S&M cuddly bear. Kay's job was to make sure these messages got paired up with the right bear packages, so the right loved one got the right sordid message.

If we looked inside of that facility, it would have been something of an assembly line. The first worker puts on Teddy's cuffs, the second person puts on leather chaps, and so on... and at some point there's Kay slipping in the customized note from the buyer. Let's say one day Big Boss rolls in with complaints that Teddys aren't keeping up with orders. He's mad and wants to get deliveries up to speed. How does Big Boss know what he should do in order to speed up the delivery of 50 Shades Teddy?

The Theory of Constraints says that the first thing Big Boss should do is look for the bottleneck. Basically, Big Boss should look around the manufacturing floor to see where work is piling up. Why? We'll let's pick on Kay and assume that Big Boss notices 30 Teddys piled up next to Kay. It's understandable since she has to spend time customizing all these sordid cards. Let's say the runner-up for backlogged work is the handcuffs guys, since they're cumbersome to attach - he has 10 Teddys waiting for him. All Big Boss cares about is getting those Teddys down the line and out to customers so that he can fill his orders. What happens if he hires the best leather chaps assembly guy in the world? Nothing. Because getting leather chaps on the Teddy Bear isn't the problem. Kay's station is known as the system constraint.

What happens once the bottleneck is identified? That's not an easy question, but here are a couple basic points. First, you subordinate other workflow stages to the constraint. In the case of Teddy, you want to make sure that maximum and best use is being made of Kay's time/effort. It would be a waste, for example, to call her off card duty to go help the guy working on the Teddy handcuffs. Since handcuff guy isn't the bottleneck, it doesn't matter if we increase his throughput. Also, when Kay goes on lunch break we'd want to allocate another worker to the card station. Even if that means another work station isn't producing, we don't care, since we want to optimize the card station. Second, we may ultimately want to consider how to elevate the performance of the constraint. Maybe - try as we might - the Teddies just keep piling up around Kay, and she just can't keep up with the need for customized cards. We may decide that we have to make investments - let's say another card-writer - to boast performance of the constraint. You don't want to jump too quickly to the conclusion that investment is required, but this may be the conclusion.

#@%* Home Depot and why efficiency doesn't matter


Inefficiency drive me absolutely nuts. As a prime example, when attorneys send endless emails to schedule group events, rather then using one of the free scheduling tools out there, causes physical agony. It's just so pathetic to waste human time and effort that way. But in truth this obsession with efficiency is misguided, because efficiency is not the goal. Effectiveness is the goal.

I was recently assigned the task - by a spouse who shall remain nameless - of installing a new hose system for the vegetable beds. As any DIYer knows, there is an immutable law of the universe that one cannot acquire, in a single trip to Home Depot, all parts required for a project. It simply cannot be done. If you were assigned the task of replacing a single 60-watt light bulb, by time you returned from Home Depot you would realize that a 61-Watt bulb was actually needed, calling for a return trip to the store.

In the case of my watering hose project, I returned from Home Depot will my hoses do-dads. But of course once I got underway I realized that one of my hose-splitters had a leak that made it useless. What to do? I could get 90% of the project done by laying all the hose and getting the sprinklers into place. But until I had the splitter the system wouldn't work, since that little widget attached the whole getup to the faucet. For sure I would be to Home Depot for another project in the next few days, so the efficient thing would be to wait for my next Home Depot trip to buy the splitter. But my wife didn't want me to be efficient, she wanted to be able to water the vegetables. My success or failure was judged by a single criterion - whether the vegetables could be gardened. Even though it was ludicrously inefficient, I got back into my truck and drove back to Home Depot, probably spending $3 of gas and $200 of my time in order to buy a $2 hose widget. Even though I did something inefficient to achieve my result, I was effective because I got the project done.

There is a saying in software development that it's better to get one feature 100% completed than to get 10 features 90% completed. Why? Because an incomplete feature, that isn't available to users, is totally worthless in the eyes of customers. The same is true for law firms. The 10 LLC formation documents that you have 90% completed are currently worthless to you and to your client. Only when a formation document is 100% complete is it valuable to the client (they have the instrument they need) and to you (now you're paid for your work and/or can close out the matter). The purpose of Agile is to get projects completed, not to optimize the efficiency at any particular work stage.

Kanban - visualize your work in production

It's Monday morning and you walk into your office. There are 329 emails in your inbox. Some are from clients with subjects that include URGENT. You have a long task list, but also know there are things you haven't jotted down. Some deadlines are looming in several of your client matters. And there's a massive legal brief that still needs a lot of work.

Some of the much-maligned stress of lawyering may be unavoidable. We work in a high-stakes, high-pressure industry. But other stressors are self-imposed. As far as I'm concerned the single most helpful component of Agile is a system for visualizing your work. The idea is to get all of the to-dos and all of the doings out of your head and into an easily understood visual representation. This is done with a kanban board.

If you've ever seen a movie about a plucky startup then you've probably seen a kanban board. The classic kanban board - made from painters tape and sticky notes - will run you somewhere between a nickle and $1. The fundamental idea is to break your workflow into columns corresponding to various workflow stages. At it's most rudimentary, it could look like this.

kanban board

In this example, cards move from left to right on the kanban board as they progress through the workflow. Note that already you can see a crucial difference between Agile and a standard to-do list: the distinction between to-do items, and things you are actually doing. Whether or not you view your self as a good multi-tasker (in fact the idea of multi-tasking is a myth - here, here, here) we all understand that there is a limited number of things we can actively be working on. I may have two complaints to draft, but I can only possibly be drafting one at a given moment in time.

A further distinction is also extremely helpful: to-do items versus tasks where you are waiting on something. This is a critical distinction that can provide a massive destressor for attorneys. So often we attorneys delegate case work to a paralegal or associate. Once you've shuttled the research task off to the associate, the case card goes into the waiting column on the kanban board. Obviously that doesn't end your responsibilities of oversight, but there's a sense of huge relief when a disappears from your to-do column. That moment is the moment your brain can say, whew, don't need to be worried about that anymore. The case is still work in production, still heading to completion, but you are not the one currently needing to action anything.

sample board 1

Let me add a bit of texture here by showing how we implemented a kanban board at our firm. We're a 100% immigration law practice, doing mostly marriage-based petitions to get residency for foreign-born spouses. These are affirmative filings, meaning our workflow is not dictated by case deadlines or adversarial action. (But note that kanban is great for litigators, and I'll give some examples below). The workflow is similar to other transactional work - like preparing estate documents - where we are working collaboratively with our clients to get a legal instrument drafted and finalized.

When we first implemented kanban we represented each client matter on a card, and organized them into the following columns:

  1. Waiting on client.
  2. Waiting on third party.
  3. To do.
  4. Doing.
  5. Done.

The "waiting on client" column was critical for us. In a typical marriage-based immigration case, we might need a hundred pages of documents from our clients, and for them to complete 20+ pages of internal questionnaires. Until we get homework back from the client, we simply can't do our part of the work. At the time we implemented kanban, I felt frustrated that cases didn't seem to be getting filed fast enough, but I wasn't sure what the hold up was. Frankly I assumed that we - at the firm - were somehow not adequately on the ball. But when we put client cards up on the kanban board, we got a distribution that looked something like this:

sample board 2

Notice where the obvious bottleneck is: the clients. Kanban gave us the law firm equivalent of Big Boss's stroll around the Teddy Bear manufacturing floor. Just like Big Boss could see Teddies piled up at particular work station, kanban quickly shows us that the bulk of our cases were awaiting action from our clients.

Importantly, remember that it is neither a good nor a bad thing that our clients were the system constraint. It's just a thing. But it's a thing that we now know to be true. Prior to kanban, maybe I would have hired an additional paralegal with hopes that it would jump start the speed of case filings. That would have been completely useless, since our production work (drafting by the firm) wasn't the bottleneck. Instead, if we want to increase the speed of throughput - the speed with which cases get closed out - then we have to work on getting a faster response time from our clients. There may be all sorts of different strategies to try in that regard, but the point is that we at least have our eye on the problem (if we decide to treat it as a problem). As just one very simple example, I now tell clients at every consultation that typically the speed of case progression is dictated by their response time; we're happy - and prepared - to proceed as quickly as they want. There's no pressure from us, but if they want the case to get filed quickly then the main factor will be their own turn-around time on their homework.

My current kanban board for cases looks more like the following. The columns are:

  1. Prospects (prospective new clients).
  2. Waiting on client.
  3. Waiting on third party.
  4. Doing.
  5. Delegated to contractor.
  6. Filed (no action possible).
  7. Holding pattern (usually prospective clients waiting on life event, like marriage, to get started on case).
  8. Done.
sample board 3

Litigation poses something of a special challenge. My firm's work is generally transaction, in the sense that that none of the case progression is governed by outside event structures: in our world, a case is completed when we've done the work to get it filed. Not so, of course, in litigation where a case's life cycle is governed by the procedures and time-tables of the court. This is a challenge when it comes to visualizing work flow, because we want to be able to know both (1) who's reasonable for the next actionable step on the case, but also (2) where the case is in its overall life cycle. For example, I want to be able to know both that the next action item is a research task by an associate, but also to know at a glance that the case is in its motion practice stage.

One inelegant solution is simply to have two boards: one that tracks next-action, like the ones shown above, and another that shows where all cases are in their litigation life cycle. That's clunky, and cuts against one of the goals of the kanban board, which is to provide a single dashboard for visualizing work-in-production. On the other hand, cases will only infrequently move through stages of the litigation life cycle (e.g., from motion practice to trial prep), so its hardly onerous to make the occasional update to the second life cycle board.

Another option is shown below. Here we introduce a vertical column designating what are commonly termed swim lanes. As a case progresses left to right (and potentially backwards at times) in its case life cycle, it also moves vertically between swim lanes to reflect the actor who's responsible for next action. This achieves the result of an all-in-one dashboard, though depending on the volume of cases this approach could result in a quite unwieldy board.


Not just for case work

The examples above are geared at using kanban to manage a client case load, but kanban is also great for managing all the other myriad to-dos of lawyer life. Most of us have many projects on our plates that don't directly relate to client work, and kanban can bring the same sanity to tracking those moving parts. My own approach is to have to separate kanban boards, one for client matters (as described above) and another for all other work. Here are the current columns on my other board, though it's something I tweak often:

  1. Ideas. The left-most column is a dump for basically any idea I might want to pursue somewhere in the future. Agile draws a sharp distinction between ideas - concepts that seem cool and worth pursuing - and to-dos that you have firmly committed to implementing. When something's put up on the idea column you're free to reconsider and dump it later. But once a deliberate decision is made to commit the item to to-do it should be moved towards implementation. (Of course the project my get dumped because it turns out to be a terrible idea, too expensive, etc., but not simply because there's no time/energy for it).
  2. To do. This column is what's referred to as the backlog. There are all projects that I've committed to doing, but don't yet have the capacity to be actively doing. Remember that one of our core missions with kanban is to identify the bottleneck in our system. The application of that concept isn't straight-forward in a personal dashboard, where you're the driving force behind all the projects on the board. But as the to do column here grows threatening long, it at least counsels against importing more projects from the ideas column, and encourages an exploration into what could be delegated.
  3. Editorial calendar. This is a pretty recent addition geared at ensuring that I get consistent and timely material out on the firm's social media channels and active blog. The neat part about this one is that it's automatically populated with cards each Monday morning. Using an application called Zapier, cards appear on the column each Monday morning with checklists to ensure we're getting out material on Facebook, google+, LinkedIn and our blog.
  4. Leads. This column is an experimental way of handling prospective clients who have contacted the firm but not yet retained us. Historically I'd used a "prospect" column on the left side of our client dashboard. But since I want to make sure these folks are top-of-mind for receiving quick follow-up, I added them to my personal dashboard.
  5. To do today. This column reflects items that I've committed to getting executed on a particular day, basically serving the purpose of the doing column. The notion is to select a sain number of items - either in the morning or previous evening - to distinguish between what's actually on your plate for the day versus in the backlog (to do column) for another day. This helps alleviate the trap of feeling that there are endless to-dos currently pressing down and needing attention.
  6. Waiting. As in above examples, this critical column holds items where no more action is possible until I get sometime from a team member, contract worker, collegue, etc.
  7. Complete. I clean this out on a weekly basis - a satisfying way to see what's been done.

Looking is free, madam

As street hawkers say in markets all around the world, just have a look - looking is free. The law practice management world is full of gizmos and do-dads that you can spend a king's ransom on. With a price-point hovering around zero I can't think of a good reason not to give kanban a try. The blue sample boards above were made using Trello, which is a cloud-based kanban tool. I like Trello, but think the advice of Agile Attorney, John Grant is good: start with a sticky-post kanban board to get a feel for it, then more to a cloud tool if you need that to meet your workforce collaboration needs. LeanKit is another popular cloud-based kanban utility that - unlike Trello - supports swim lanes. LeanKit is far more feature rich, though as is usually the case for software that's not a plus if you don't need the features. After over a year I'm still happily using Trello.

Dig deeper

If you want to explore more about Agile lawyering, check out these resources:

  • John Grant is the granddaddy of the Agile attorney movement - blog here.
  • This is the original cred of the Agile movement.
  • The Goal (and on Audible) by Eliyahu Goldratt, is the definitive "business novel" that explains the Theory of Constraints. It's painfully corny, but also instructive.
  • John Grant runs an Agile attorney group on Slack (like a discussion forum) - sign up for free here.

Slides from King County Bar Association talk (May 4, 2016)