Kanban for Lawyers, Part 2: A Retrospective


If you haven’t already, you should probably go check out my last post, which is essentially Chapter 1 of my in-progress book Kanban For Lawyers. As I write this, I’m currently wrapping up the 8th chapter and I plan to publish it to the LeanPub version of the book next week. Right now you can buy the book on LeanPub for as little as a dollar, and if you do so you’ll be entitled to automatic & free updates as I add new content to it. When you buy you can choose (and switch between) versions for Kindle, iBooks, most other e-readers, and of course PDF.

I’ve had good feedback from Chapter 1, and while I love the kudos I want to hear the criticisms too. Let me know what you like, what you don’t, and what you’d like to see that’s different (and if you’re paying attention, you’ll recognize these questions as variants of the whole point of this next chapter).

Also, another shout-out to Agile Attorneys Community on Google+ where you can connect with, and learn from, other legal professionals who are using Agile in their practices. And, as always, don’t hesitate to contact me if you want to discuss any of these ideas further. Thanks, and read on!


Kanban for Lawyers Chapter 2: A Retrospective

Wait a minute—we’re one chapter into this book and already we’re having a retrospective? Seems a little premature, doesn’t it?

Bear with me.

When I said before that completing your “Build Kanban Board” task was a small accomplishment, I was lying. You have actually accomplished a great deal.

First, you have conceived, implemented, and tested a Minimum Viable Product*. That is, you have created a simple thing of value that you can actually use right now to accomplish your work. Oh it is going to get better—a lot better actually—but you’ve built something: A good start.

Equally important, you’ve learned something from the act of building (and from the act of using) your creation. You are now a little bit smarter, a little more experienced. Everything from here forward will be improvement.

Second, you have made your workflow visible. Granted, what you have on your wall right now is a crude approximation of your workflow, but the basic structure is there. We’ll tease out some more detail shortly (maybe a lot of detail eventually). Even this simplistic level of workflow visibility, however, will begin to unlock the incredible power of Kanban.

You have also made your work visible. Well, one task is visible for now. But you saw it! An actual, tangible task that you took from conception to completion through your workflow.

As lawyers, especially modern computer-oriented lawyers, our work is largely invisible. We do lots of things every day, possibly every hour, but we don’t really see most of them. A contract reviewed, a motion drafted, some research done—all of the progress typically lives in our heads, or at most in the ones and zeros of our devices and the ephemeral glow of our displays. We may print off something on occasion, but we quickly send it away to somewhere else. Our work is hard to see.

As humans, this is foreign. We evolved while doing physical, tangible things. If we needed to gather food, we went out into the physical world and plucked edibles until we couldn’t carry any more or it was time to eat. If we needed greater capacity, we wove physical baskets that started with nothing but a pile of reeds and, through a process, finished with something significantly more valuable.

This series of events—identifying a need, inventing some methodology for meeting that need, and then refining the methodology to satisfy the need more effectively—is the baseline for all human progress. It is what distinguishes human progress from evolutionary progress, where a random mutation renders an individual slightly more or less fit to succeed in its particular environment (and, if all goes well, successful mutations are passed along to the next generation).

There’s the thing: Evolution requires generations to progress, but Humans can conceive, build, test, and improve much more quickly. Think about that. Conceive. Build. Test. Improve. Just pondering those steps feels like progress.

My point is that we are much better at interacting with the physical world than the virtual one. If you disagree, then ask why our virtual devices are constantly becoming smaller, more portable—from ENIAC to desktop to laptop to mobile to wearable. I tend to think it is because most people want our devices to accompany us into the world at large where they compliment, not supplant, our physical experience.

Kanban gives all of your invisible, virtual work a visible, physical analog. It isn’t quite the same as doing actual physical work, but it is enough to trick your lizard brain into experiencing the work in a more familiar way. This, in turn, allows your brain to start doing what it does best: recognize patterns, categorize items, perceive threats and dismiss trivialities. Once you can actually see your work in a Kanban board, you will experience a sense of order and control that has no-doubt been missing from your work-life for some time.

The third thing you have accomplished (or the fourth, it isn’t important) is that you’ve experienced the power of working on one thing at a time, and of working on it until it is done. In manufacturing this is called Single Piece Flow. There is decades of evidence showing that Single Piece Flow—as opposed to the alternatives, multitasking and batch flow—is the best way to get lots of things done in a fixed amount of time. There is other, more recent, evidence that we humans are pretty lousy multitaskers (texting and driving is a familiar example), and don’t get me started on batch flow—a false idol of misperceived efficiency if there ever was one. But we’ll dive into the concept of Flow very soon.

Finally (for now), you are about to complete a Retrospective. This should become as familiar a part of your personal cadence as brushing your teeth. This first Retrospective isn’t actually a great example—I’ve been a little long-winded and we haven’t followed much of a structure. But we can fix that now.

As you develop a habit of retrospection**, I find it helpful to ask the following three questions:

1. What went well that I should keep doing?
2. What didn’t go well that I should stop doing?
3. What should I try next time that is different?

This chapter so far has focused on the first question. Although you may not fully understand all of the whys yet, many things went well when you used Kanban for the first time. We won’t always go into such detail, but acknowledging and appreciating success helps to reinforce it. Early success, no matter how small, establishes a foundation for progress.

As for the second question, I’ll leave that mostly up to you. Perhaps you didn’t choose the best section of wall, or your writing was hard to read, or you ran out of room on your stickys, or who knows what else. For me, I’ll admit again that this first retrospective is taking too long.

This isn’t the time to beat yourself up. The shortcomings aren’t nearly as important as the successes, for they can always can be fixed. This also isn’t the time to do the fixing; it is a time for thinking. More diagnosis, less prescription.

Spending time just thinking may be harder than you suspect since our culture predisposes us to want to take action. To everything there is a season, however, and the season for reflection is every bit as important to your cycle as the season for doing.

The third question also requires some discipline, especially in the early stages of Kanban. Already your mind may be racing through different ideas about how you can improve your board, define your tasks, or maybe get other members of your team up there. These are great, and we’ll want to consider them all, but not immediately. For each idea you have, write it on a sticky note and put it on the wall to the left of your To Do column.

Wait… To the left of “To Do?” That sounds like we need to add a column to our Kanban board. Let’s start there.


* The Minimum Viable Product concept comes from Eric Reis’s excellent book The Lean Startup. It is an essential guide to entrepreneurship and product development that any technology client of yours has almost certainly read. If you have technology clients, you should get familiar with it so that you can better connect with those clients. But even if you don’t, its concepts will absolutely help you improve your own practice and better understand your value proposition to your customers.

** Weekly is great, every other week is totally fine for personal work or smaller teams. If you stretch it to monthly you’ll probably find that you have too much to handle in a single Retrospective. As you start with Kanban (and Agile methodologies in general) I’d say more frequent retrospectives are better. Once you get the hang of it, you may or may not want to stretch them out over time.


© 2015 John E. Grant

Photo Credit: kris krüg, licensed under CC BY-SA 2.0

  • When we discussed introduction of some board like for instance, first assumption was to make everybody’s work visible as you said. It changed workflow totally. There is no need to do the ‘trips’ to project managers, resolvers and other stuff. It so simple that I am wondering why it was invented so late.

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}