« Four ways to simplify legal process improvement (Part 3 of 3) | Main | Agile legal project management: What works and what doesn’t (Part 2 of 2) »

November 16, 2016

Agile legal project management: What works and what doesn’t (Part 1 of 2)

By Paul Saunders, Practice Innovation Partner, Stewart McKelvey

Background on these guest posts: When we published the fourth edition of our Legal Project Management Quick Reference Guide a few weeks ago, some of the most important articles were the new sections on Agile, a flexible approach to managing projects that is well-suited to the rapidly changing nature of many legal matters. Two of the book’s Agile articles were written by Paul Saunders, the author of these guest posts. While many experts have written about the potential value of Agile to lawyers in theory, Paul is one of the very few who has actually applied and tested the concepts in his firm. A few weeks ago, when Ivan Rasic of LegalTrek contacted me to provide input to his “How to Make a Strong Legal Team with Agile Project Management,” I suggested that he also contact Paul. Paul wrote a long and informative email which evolved into the guest posts below.

I wrote in our fourth edition that I “expect the fifth edition to include many more examples [of Agile, as the approach] continues to spread” (p. 25). This prediction is already becoming true. At this time, the evolving fifth edition is available only to firms that subscribe to our new on-line version. (The printed fifth edition will be published in a few years.) However, in the meantime, LPM is growing so rapidly that occasional sections from the fifth edition will appear in this blog, starting with these posts. – Jim Hassett


I recommend that law firms start Agile with something simple and easy – a minimal solution to acclimate the group to this new way of thinking. Then repeat and revise that solution over and over again, based on feedback from the group. (This approach is based on the “Build-Measure-Learn” feedback loop Eric Ries described in his book, The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.) This avoids the potential problem of spending months building something that no one is prepared to use.

I often start by introducing a team to the basics of Kanban and Scrum in an hour-long meeting and put together a quick task board on a whiteboard. The team then maps out all the standard stages that a portfolio of matters would proceed through and places cards within the stages to represent active matters they are working on. As a follow-up, the team conducts the equivalent of Scrum stand-up meetings at a frequency that makes sense for the team, with each team member answering in no more than two minutes the three core questions of Scrum:

  1. What did I do since the last meeting?
  2. What will I do before the next meeting?
  3. What’s blocking me or what do I need help with?

I then schedule review meetings (perhaps every month or two) to see how things are going and try to reach team consensus around three other questions:

  1. What’s working?
  2. What isn’t?
  3. What should we try differently?

When trying something differently (say, for example, transitioning to a digital Kanban tool), we come back to the minimal solution again. Change something, get feedback from the group, and change it again until it works well for the team.

I’ve found that these methods require one magic ingredient to work well: each team member must have a vested interest in the outcome of the work of others on the team. We’ve run projects applying this method which didn’t work well, where participants weren’t really part of a team but just did similar work within a similar department or with the same manager. They found the time spent giving their updates and hearing what others were doing was a waste of their time since they were all working independently anyway. Managers found it helpful to give them a sense of what everyone was working on, but if the team members themselves don’t see utility in it, it won’t have the desired effect.

However, within groups that did have a vested interest in the outcome of other members and who were expected to work together (for example, a project team on a big matter or the client service team for a major firm client), we have found these methods very effective at eliminating bottlenecks and in increasing transparency and creating accountability within the teams to progress their matters between meetings.

Comments

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.