Agile legal project management: What works and what doesn’t (Part 2 of 2)
Some other Agile concepts have proven less useful, at least at our firm. For example, some experts have written about the potential value of Agile sprints to law firms, but that has not been our experience. (An Agile sprint is “a well-defined period of time during which specific work must be completed. Each sprint begins with a planning meeting in which the person requesting the work and the development team agree upon exactly what work will be accomplished during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria need to be met for the work to be approved and accepted.”)
We haven’t found much utility using this concept, since in most cases the nature of our legal work is ongoing, without any distinguishing features that create a natural divide between different phases. For example, when managing a portfolio of matters or trying to close a major transaction at month-end, where everyone is continually working anyway, we felt that grouping the work into sprints could actually be a bit limiting. If a client asked for work that wasn’t planned in this sprint, the work would have to be done anyway. Perhaps other firms or law departments would have a different experience.
We also tend to not use the Agile terminology at the early stages, since that can sometimes turn off people who are already skeptical of the method. For example, I’ll often use the term “task board” instead of Kanban, “review meeting” instead of Retrospective, and “project manager” instead of Scrum Master, at least at first. Once the team sees the benefit of the Agile method, I’ll then provide the jargon in case they want to do some additional research to learn more.
Another Agile concept which has proven quite useful in software development but not in our firm is the idea of a WIP (work-in-progress) limit. (This has been defined as “a strategy for preventing bottlenecks in software development. WIP limits are agreed upon by the development team before a project begins and are enforced by the team’s facilitator. For example, a team may divide the tasks that must be performed for a feature into design, code, test, and deploy. When a WIP limit for a certain task has been reached, the team stops and works together to clear the bottleneck. The goal of working in this manner is meant to ensure that the entire team takes ownership of the project and produces high quality code.”)
In our legal work, it is very difficult to place WIP limits on people since it is tough to gauge how much time each task will take to complete. In addition, in many cases the work listed on a task board is just one of their assignments and their time is limited by their assignments to other legal matters at the same time. At our firm, a WIP limit is better dealt with by simply asking each individual whether they have capacity for a particular task or not.
Finally, at Stewart McKelvey, our approach has been to pick and choose big ideas from a number of different methodologies, including Agile, Waterfall, Lean, Six Sigma, Change Management, and others. We simply use and adapt the tools and ideas that fit each scenario.
Some Agile experts are a bit more dogmatic and argue that you have to strictly follow the complete system to reap the benefits. We’ve found that starting with the core ideas in their simplest form is the most effective way to get that buy-in early on while also being flexible to pivot to other ideas as needed. I see real value in utilizing traditional project management methods simultaneously with Agile, particularly with respect to developing and managing budgets and estimates, setting scope, and so on.