In my last post I explained why Agile case management processes may be particularly applicable for the management of matters commonly classed as legal project work, identified as large and complex matters found in the practice areas of:
- Dispute Resolution (especially areas such as complex construction disputes)
- Banking and Finance
- Commercial Property transactions
- Legal aspects of software development and IT installation
- Corporate and Commercial work including M&A activity.
I am not suggesting that these categories of matters can be managed only according to Agile principles and practices, nor am I suggesting that Agile principles cannot be applied to other practice areas. However it does seem to me that project lawyers could benefit more than most by applying Agile techniques to legal solution delivery. (I think it more appropriate to refer to the delivery of a ‘legal solution’ rather than ‘legal services’ – after all, this is what client’s want, a legal solution to a problem they have).
So what is an Agile approach to case management? How might it work in practice? An Agile approach to legal case management should be made up of three elements:
- A Framework
- A set of practices
- A state of mind.
While it is true that Agile emphasises responsiveness and solution delivery as opposed to a preoccupation with processes and procedure, the fact is there is a framework which is recognisably Agile. Many people seem to think that Agile is simply working quickly; but teams working quickly without a framework and high level direction are unlikely to be as efficient, effective and creative as they could be. A classic Agile framework, including roles and supporting procedures is outlined below. I have seen this framework work well in software development organisations and I have sought to make it a little more relevant to a legal practice environment.
There needs to be a product owner. The product owner has responsibility for the ultimate delivery and overall scope of the legal solution. The product owner should be the lead partner on the matter, as the product owner will interface most – at least initially – with the client. The product owner needs to direct the team towards the most valuable aspects of the legal solution. The product owner does this by:
- Understanding and articulating key client needs – the product owner becomes the voice of the client within the delivery organisation
- Managing the ‘product backlog’.
The product backlog is the list of client requests on a particular matter. The requests should be captured and represented in plain English rather than legal jargon. If truly implementing Agile, they should be expressed as ‘user stories’. A user story is set out in the format:
As a <role type> I want to be able to <do something> so that <I can achieve something of value>.
When acting for commercial organisations, although the principal contact will be the in-house lawyer, there will invariably be a number of other parties in the organisation with an interest in the legal work. User stores are a good way of capturing requirements from different viewpoints, which can then be used to deliver a more valuable solution to the client – ie the commercial entity funding the instructions, not solely the in-house lawyer articulating them. Suppose your firm has been instructed by a landlord of a large number of commercial properties. The basic instruction may be to review all leases and standardise key terms. Different people in the client organisation may have differing motivations behind the request which may be expressed as:
As the Managing Director of XYZ Ltd I want all leases standardised so that I can prepare to divest certain types of property more easily in future.
As the Finance Director of XYZ Ltd I want all leases standardised so that revenue can be maximised during the next 3 financial years
As the Head of Legal Services of XYZ Ltd I want all leases standardised so that their administration and maintenance is made easier for my team.
These high level user stories can be broken down further detail, with more user stories added as and when required.
You may well be thinking what is the point? If the instruction is to standardise the leases, why not just go ahead and standardise? The point is that capturing user stories should help illustrate where the true value of the legal work lies. They should also help scope (see below), cost and price the work better. This is particularly relevant in a value pricing environment. Collecting and recording user stories like this should help you develop your pricing options for the work. Rather than simply follow basic instructions and bill and the end of the matter (and probably discount a lot of time along the way) taking time to consider wider organisational requirements means you can better identify client needs and wants and devise a range of solutions – with differential pricing – for the client to consider.
The product owner is responsible for the order, and ranking, of the user stories in the master product backlog. Ideally the product owner should also agree and record with the client, and then explain to the delivery team, the acceptance criteria for the legal solution to each user story.
The delivery team is made up of everyone significantly involved in the delivery of the legal solution: lawyers, paralegals and secretaries. The team should take collective responsibility for estimating how long providing solutions for all user stories will take. In conjunction with the product owner, the work should be split into a number of discrete delivery stages (known as ‘sprints’ in Agile terminology). Lawyers are lucky here as there will often be an obvious – indeed procedurally necessary – ordering of events which can be grouped together as stages or ‘sprints’. Litigation may appear to lend itself most readily to a sprint approach. One issue however is that the optimal timeframe for sprint – an intense and focused effort of work – has most often been found (in software development at least) to be between 2 – 4 weeks in duration. Complex litigation can last for years with the discovery phase for example lasting many months, so some creativity is needed here regards sprint duration. It would be better to think of sprints as objectives, in which case even a long discovery process can be broken down into shorter segments, each with a specific objective.
Research (see here for example) and personal experience has shown that an Agile approach improves solution scoping and more accurate estimation of costs. These improvements flow from two things: being able to focus on a sub-set of the entire project, ie being able to focus on the scope of individual ‘sprints’, and the estimating effort being done by the delivery team collaboratively. No one person should be tasked with the scoping and cost estimation; these tasks should be team efforts.
A team coach (usually referred to as a ‘scrum master’ in Agile terminology, but I prefer term coach) should be available to guide and assist the team. I’d suggest the team coach should be a senior secretary or someone similarly recognised as having significant clout in administration matters. The team coach needs to guide and assist the team and this is achieved by:
- Clearing out practical impediments in the way of the team as it moves towards its sprint objective.
- Monitoring the work done by the team and comparing this against target completion date.
The principal means of doing this is by means of a short (5 – 15 minutes maximum) and focused, daily team meeting. At this meeting the coach should ask each individual team member:
- What tasks did you complete since yesterday’s team meeting?
- What tasks do you expect to complete before the next team meeting?
- Are there any obstacles in your way to completing these tasks? (If so, what?).
Daily team meetings – no exceptions, all team members must attend – are a good way of injecting a sense of urgency into the project. The daily team meeting should not be allowed to become a forum for discussing issues, as this can be done elsewhere. The daily meeting is really designed to keep the process going with sufficient velocity. This meeting, and the role performed by the team coach, is also crucial for containing costs. If obstacles (which could include anything from a damaged printer to needing to get hold of a specialist textbook or precedent etc) can be cleared out of the way in good time, then the team can keep being as productive as possible with minimal down-time.
The team coach should keep track of the team velocity by making note of completed tasks and then comparing the estimated time for the tasks remaining in the sprint with the amount of work-time available until the end of the sprint. Obviously if there are any negative variances – so that there is a risk that all sprint tasks will not be completed in time – then this needs to be flagged up to the product owner and the team with action taken to bring things back on track.
Another major benefit of an Agile approach is that both client and the supplying organisation should be able to see the outputs from each completed sprint. When developing software, at the end of each sprint development teams will walkthrough the development to date with all relevant stakeholders. The purpose is to acquire feedback – is the development on track? Is this what the client was expecting? I see no reason why this principle cannot be applied to legal matters; regular formal walkthroughs with the client, taking the client through all the artefacts produced to date and summarising progress of each sprint must surely help improve client communications. It should also give all concerned a chance to pause and consider progress. As a result, there may well be a change of emphasis in succeeding sprints – hence the ‘Agility’ afforded when needing to react to change during matter (project) progress.
I will deal with the most common objections to implementing Agile in my next post but there is one issue in particular that needs to be addressed here. To be effective an Agile approach requires a considerable amount of planning by, and communication between, team members – the most obvious manifestation of the latter being the daily team meetings. In an environment where time is charged to clients in 6 minute units, such an approach may be very difficult to justify. However my contention is that an Agile approach is particularly suited to large complex matters which are priced by value rather than time, where the most important thing by far is developing a solution which reflects the price the client is willing to pay.