On the legal conference circuit, the topic of working in an “Agile” environment has been cropping up so frequently, you could be forgiven for thinking it’s a hot, new project management method. But try bringing up Agile with someone from a software or technology background and they’ll likely scratch their head and wonder why the fuss.
This is because Agile is not a new concept. In fact, it began as a movement during the “dot com boom” of the 1990s, springing from the need to modernise software development methods. A group of web developers met at a resort in Snowbird, Utah in 2001 to share ideas and the result of their collaboration was to publish the Manifesto for Agile Software Development. The manifesto sets out the principles and values of the Agile philosophy, which in turn underpin how these different methodologies work.
Despite the process and basic principles of Agile project management not changing much since, many industries and workplaces have only cottoned on to it in recent years. In a world of increasing technological and economic change, more organisations have realised that there are a range of benefits to embracing this way of working.
What is Agile and why is it valued?
To put simply, it’s a project management framework and structured method of organising teams to get work done. More precisely, Agile is an umbrella term for several different frameworks or methodologies, with one of the most well-known being “Scrum”.
With Scrum, a project is divided into short and incremental phases of work (called “sprints”). These are separated by regular reviews which allow a team to re-prioritise tasks and adapt their planning to reflect what the customer might want next. This flexibility and adaptability allows the customer’s requirements to evolve during the project, such as when new information comes to light.
Another key principle of Agile is that each sprint must deliver something immediately workable, or provide an outcome of value to the customer. In software development, this is called a “potentially shippable increment”, which is an upgrade or feature that the client could feasibly release to its software users. For instance, the output might be a prototype version of a new product or the first draft of a report. This is to ensure, that by the end of a sprint, should the client decide to discontinue the project to focus on other initiatives, at least something of value has been created.
Agile keywords explained
Agile uses its own terminology to define different roles and project tools and places importance on the use of this common language. Key expressions include:
Product owner. The customer representative that defines the product vision and sorts the development tasks in terms of priority.
Development team. The team that carries out the work. The team should be between three and nine people and include the right mix of functional skills to be able to complete all tasks.
ScrumMaster. Acts as a coach, facilitates the development process and removes obstacles that might hinder the team’s progress.
Sprint. A period over which work will occur (usually two to four weeks). The sprint starts with a planning meeting and once started, the team works only on the tasks allocated to that sprint. The sprint ends with a review meeting.
Daily stand-up. A daily meeting of the team, where each team member reports what work they have completed, what they are planning to do and any obstacles faced. It is held standing so that it is finished quickly (no more than 15 minutes).
Product vision. A precise definition of what needs to be developed, focusing on business goals and targeted benefits.
Product backlog. A prioritised list of the customer’s business requirements that are to be developed during the project term. Each development item will be given an estimated business value and estimated effort, so the priority can be worked out. Often development items will take the form of a “user story”. The tasks allocated to a particular sprint are listed on a “sprint backlog”.
User story. A short description of what is required, in the language of the business end-user. This is usually expressed using the formula “As a [describe role], I want [describe feature or objective], so that [describe benefit or reason].”
Why Agile can be useful for lawyers
Many leading companies have adopted Agile as a framework to transform their business activities across a range of focus areas, including research and development, customer experience, as well as operations and strategy. And you could argue that Agile looks like it is here to stay, with big tech company Atlassian splashing out US$165 million this week to purchase AgileCraft, a service that helps enterprises plan and monitor their strategic projects using Agile.
So what benefits can legal professionals get from learning about it? Well, for lawyers to be truly client-centred and commercial, they should have a good understanding of how their clients work. If clients are using Agile, then those clients are likely to expect their lawyers to know how it works.
Lawyers may have clients who are collaborating with service providers, suppliers, customers or consultants for instance. An Agile-based approach to the project will require that the contract accurately reflects how the parties will work in practice. So trying to document the parameters of an Agile project using a contract template suited for a more traditional project management method is likely to be a recipe for disaster. Where clients are using Agile, their lawyers need to look at the usual contract issues from a fresh perspective.
Key factors to consider:
- Term and termination provisions. These will need to reflect the number and duration of planned sprints. Clients will want termination for convenience rights, should they wish to bring the project to an end early, and these will need to be factored in when planning sprints.
- Pricing and payment provisions. Clients can get concerned that an Agile project will be expensive, because it risks being too open-ended. Expect the possibility of different views about who bears the risk of going over budget.
- Warranties and risk allocation provisions. If a project team comprises a mix of representatives from different organisations, it can be difficult to apportion blame for events that give rise to a contract breach. This makes standard risk allocations provisions more difficult to negotiate than usual.
- Dispute resolution mechanisms. Agile requires the project team to be able to keep collaborating without distractions, even if there is a contract dispute going on in the background. Suitable dispute resolution provisions are essential.
Agile as a business advantage for lawyers
Beyond helping their clients with Agile projects, lawyers themselves are looking at whether they can bring these methods into their own practice too, to improve their client service delivery. For lawyers working on complex projects, such as mergers and acquisition transactions or large-scale litigation, adopting this project management framework may be a way to improve flexibility, client responsiveness and reduce wasted work. Talking to lawyers from across the market, there are already several case studies of legal teams successfully basing their workflow around Agile principles and reaping the benefits.
Lawyers can sometimes be cynical about management fads or buzzwords. But beyond the hype, there are now more and more legal professionals asking themselves if Agile could be the way for their team to operate more effectively.
Practical Law includes a detailed practice note on the legal and practical issues raised by Agile projects and contracting. Learn more about Practical Law or request a trial today.
