November 01, 2017 GPSolo

Make Your Law Firm Agile: Apply the Management Secrets of Software Developers

Jeff Kerr

The legal industry is inherently conservative—not in the political sense, but in the sense of honoring and adhering to traditional practices. Indeed, when we’re searching for the answer to legal questions, the answer lies in how courts resolved similar issues in the past. We’re trained to study and honor tradition; we’re not trained to innovate.

But as the world in which we work changes ever more rapidly, attorneys’ willingness to innovate may be one of the most important predictors of their ability to survive—and even thrive—in the changing environment. Clients and legal departments are increasingly demanding more value and bang for their buck, and attorneys who adhere to traditional, inefficient work habits that waste billable hours will find themselves at a competitive disadvantage from those who adjust.

For many knowledge workers, rethinking and reengineering the way we work by applying methods devised in the software industry have been key. In this article, I’ll explore whether lawyers can apply the organizational methods Agile and Scrum—devised in the tech sector to do “twice the work in half the time”—in the world of law practice management. I believe the answer is that we can.

Agile Is Catching On in the Law

Agile is a set of 12 principles devised by a group of software engineers in the early 2000s. It was designed to improve the process of developing and delivering software. (For an overview, see agilemanifesto.org/history.html.) There’s a lot of buzz about Agile. Studies of the use of Agile report increases in productivity, project visibility, employee morale and motivation, quality of products and services, transparency, and predictability (tinyurl.com/ychyafox). Agile is also said to reduce risk. Although rooted in software development, Agile methods have been adopted in numerous industries, including higher education, manufacturing, and even the military.

Together, the Agile principles emphasize flexibility, the need to embrace change, collaboration, face-to-face communication, allowing teams to self-organize, trusting team members to get the job done, sustainable pacing, simplicity (work left undone), tangible results, and regular reflection on measures to increase the team’s effectiveness. The 12 principles of Agile are worth reading (agilemanifesto.org/principles.html), but they are more a collection of values and preferences than a system for work. Because of the abstract—and admittedly somewhat “mushy”—quality of the Agile principles, most people turn to a more concrete system, such as Scrum, which is by far the most popular and widely used Agile methodology (tinyurl.com/y8p2hxde). I’ll now turn to Scrum, and it will represent Agile for the remainder of this article.

The Basics of Scrum: The Most Popular Agile Framework

Scrum is organized around several key concepts: sprints, sprint planning, stand-ups, sprint reviews, user stories, and kaizens. A handy introduction to Scrum can be found in the article “Embracing Agile” in the Harvard Business Review (tinyurl.com/jsypuou), but I’ll provide a very brief introduction here as well.

The work in Scrum is done by a team, ideally of no more than ten people. The team works in “sprints,” which are cycles of between one and four weeks. Each sprint begins with a planning meeting, where the team picks a set of deliverables from an ordered backlog of tasks (also called “user stories”). During the sprint, the team completes the tasks chosen during planning. On each day of the sprint, the team has a brief meeting (usually 15 minutes) called a “stand-up” where all team members state what they did the day before, what they plan to do that day, and whether they are blocked on any tasks. At the end of each sprint, the team has a review meeting, ideally presenting some sort of deliverable to the customer or client. The review should also include a candid assessment of what went well and what went poorly during the sprint, and the team should attempt to come up with a concrete process improvement called a kaizen (Japanese for “good change”) to be implemented in following sprints.

The basic pattern above usually also includes a role on the team known as the product owner. The product owner is charged with ordering the backlog of tasks and ensuring that tasks are well-defined. Textbook versions of Scrum also include a role known as the Scrum master, but it seems unlikely that this role would ever be filled in a small law firm, so I’ll pass over it here.

Another helpful element of Scrum is the unit of work known as a “user story.” A user story is a sentence written in the following form: “As a [type of user], I want [description of deliverable], so that [problem to be solved].” For example, a story for a company building legal software might be: “as a managing lawyer, I want to see a list of cases for each attorney in the firm so that I can make sure everyone has enough work.” Phrasing the story/task in this way will help whoever is assigned this story to understand why the task must be done and how it will help the end user. Finally, Scrum also includes a concept known as the “definition of done.” Teams should have clear criteria for what it means for a story to be completed. Doing so removes ambiguity, improves accountability, and helps maintain consistent quality.

Applying Scrum to Legal Work

All my significant work experience is in small businesses, where it is easy to meet with the entire team and to know, more or less, what everyone is doing on a daily basis. I was one of two founding partners at a small law firm where we did not use Agile methods, and I am the founder of a software company (CaseFleet) that is very committed to Agile methods, Scrum in particular. Scrum has been so overwhelmingly helpful to us that I recommend it strongly to anyone working in any field. Even if you are a sole practitioner working from a home office, you can benefit from the rhythms and processes of Scrum. Still, most of the benefits of Scrum arise from its impact on team productivity, so I’ll focus on this aspect here.

To get started with Scrum in a small law firm, you’ll first need to get your team on board. This often comes from the top down, and that’s okay. It can be very helpful to have your team read about Scrum before you start doing it. At CaseFleet, we all read Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland (Crown, 2014) before diving into Scrum. Then we picked an interval for sprints (one week, later changed to two), and we planned our first sprint. The framework for Scrum is fairly simple: Choose a set of tasks to complete each sprint, have daily stand-ups to update each other on progress, and meet at the end of the sprint to consider ways to do it all better the next time. Rinse and repeat. You can and should start simple. You don’t need to track your velocity, and you don’t need to worry excessively about whether you’ve written your tasks properly as user stories.

To sum up, here are the steps you’ll need to take to start using Scrum in your law practice.

  1. Learn the basics of Scrum. Reading Scrum: The Art of Doing Twice the Work in Half the Time will teach you everything you need to get started.
  2. Get your team to commit to having the following regularly scheduled meetings: a sprint planning meeting at the beginning of each sprint, daily stand-ups (no more than 15 minutes), and a sprint review at the end of each sprint. The planning and review meetings often last an hour or more.
  3. Prepare a backlog of stories/tasks.
  4. Pick a duration for your sprints.
  5. Schedule your first sprint planning meeting, and go.

Challenges

Based on my experience using Scrum at CaseFleet and my experience working at a small law firm, you should anticipate a number of substantial but not insurmountable obstacles to using Scrum in your law practice.

First, it’s impossible in most law practices to pick a set of tasks in advance and then work exclusively on these tasks for any length of time. We’re often having to respond to unforeseen developments in our cases (say, the other side files a motion without any warning) or from our clients (some emergency), and these events can force us to drop everything and replan entire weeks of work. Scrum isn’t designed for these sorts of situations. Scrum would prefer that your work be predictable within the unit of time defined by the sprint.

To deal with this problem and to accommodate the realities of running a law practice, you’ll need to find a balance in how much you take on each sprint so that you leave yourself enough time to deal with crises and unforeseen developments. Typically, you want to have a rock-solid commitment to getting everything that you decided on in sprint planning completed during the sprint—come hell or high water—but in reality, there will be sprints when you can’t complete everything. Fortunately, this is why you have kaizens (concrete improvements) and sprint reviews. After each sprint you’ll learn more about how to manage these concerns, and your process will continuously improve.

The next challenge you’ll encounter in a law practice is dealing with long-running or continuous tasks. In a law practice, these could be tasks such as “inform all clients of updates in the status of their matters.” On the one hand, it can be difficult to determine when these tasks are complete. On the other hand, even if such tasks are clearly completed in a sprint, they just end up being added to the next sprint. Seeing these tasks again on every new sprint makes them feel like boulders that roll back down the hill every time you push them to the top. You may decide to leave these tasks off the list of stories in your sprint, or you may leave them on. The best answer will be dictated by your team’s experience.

Role of Software

When using Scrum, you must have some sort of system for maintaining a backlog, seeing which stories are on the current sprint, and tracking the status of each story (e.g., to do, doing, or done). Some experts recommend using a physical wall somewhere in your office as a sprint board, using sticky notes as stories, and having columns for each status: to do, doing, and done. As someone who does a lot of work outside the office, this approach never appealed to me. Indeed, most people starting Scrum want to know which software tool is best for the job. There is good news and bad news here for lawyers. The good news is that there are many powerful and well-designed software tools for Agile workflows. The bad news is that nearly all these tools were designed for software developers and the features they offer for this market (GitHub integrations, bug tracking, and the like) can be confusing and irritating to non-coders. Hence, most experts punt when it comes to recommending software to help lawyers implement Scrum, but I will take a stab at offering some recommendations. These are no doubt idiosyncratic and somewhat personal choices, so keep this in mind when evaluating them.

  • Trello (trello.com). This is a very popular, visually pleasing, and quite powerful tool for organizing tasks and moving them between columns representing their status. It’s intuitive and easy to get started, but it can get cluttered once you add a lot of tasks. It’s also possible you’ll reach a point where you’ll feel like you’ve outgrown the tool (this happened to us).
  • Airtable (airtable.com). The benefit of Airtable is that you can structure data however you want. You can probably get closest to a system that has all the ingredients of textbook Scrum with Airtable, but you’ll have to build it yourself (or else find a good template). Note that you should get your team’s feedback before committing to any solution. If your team members strongly dislike the app you choose, getting them to use Scrum may prove difficult.
  • Clubhouse (clubhouse.io). This is my personal favorite, but it requires tweaking to add Scrum workflows. Some users find the interface to be complex, but I find it has all the right ingredients for managing a team’s stories. This is the tool we use at CaseFleet.

Conclusion

Scrum and Agile can transform the way you work, increasing not only efficiency but also satisfaction. The hype around them is warranted, and there’s no reason Agile methodologies shouldn’t catch on in the legal industry. If I were practicing law right now, I would insist on using Scrum. It is too powerful and beneficial to pass up. If you haven’t tried it yet, you should try it at your firm.

Jeff Kerr (casefleet.com) is the founder and CEO of CaseFleet, providers of legal case management software designed to help litigators win more with tools for reviewing case evidence, organizing facts, developing case timelines, and more. Jeff previously was the co-founder of a litigation firm focused on employment law. He is a frequent speaker and writer on the importance of technology in the practice of law and how technology can improve lawyers’ efficiency and effectiveness.