Agile Software Development in Law Firms - 7 Key Learnings
A lot has been written on the pros and cons of Agile in law firms. Remind me what Agile is again? Agile is an approach to project management in software development, often seen as an alternative to Waterfall. Unlike Waterfall, where the end-product is delivered in one fell swoop (likely after a significant passage of time), Agile uses incremental, iterative work sequences called "sprints" to release product regularly. These sprint cycles make Agile versatile enough for the unpredictability of constructing software and therefore less likely to fail. I'm still lost. This video by Henrik Kniberg is a great intro.
Nonetheless, even for software development, Agile doesn't necessarily work out of the box in a law firm. As a Product Owner on Agile software development projects (mainly internal builds automating complex legal analysis), I picked up seven key learnings that really enabled my projects. These might be particularly helpful to lawyers and / or innovation professionals taking up the role of Project Manager or Product Owner for the first time.
One obvious point not specific to Agile, is the importance of a strong team. Luckily, I had fantastic teams on my projects and was guided by talented individuals throughout.
1. Ensure your structure, budget and communications reflect project / product scope
Make sure that the project is appropriately structured, budgeted and communicated to reflect its scope. This is made much easier if you have only one product per project.
This is a great way to keep expectations aligned with your team's output, avoiding the pressure that comes with any misalignment. Can you give me an example? If your project promises product "Z", then your stakeholders and sponsors will assume that you are delivering Z only, without major dependencies. If in fact you also need to deliver products "X" and "Y", your stakeholders and sponsors might not understand why there is a delay in releasing product Z. This is because you have not structured, budgeted, or communicated the full product matrix - meaning your project starts in the basement rather than the ground floor.
Ideally, have one product per project or reflect the product matrix in structure, budget and communications.
2. Delivering the "MVP" requires constant discipline
The Product Owner has to constantly filter “must haves” from “nice to haves” in order to deliver just the minimum viable product (“MVP”).
This is especially hard in a target rich environment with many "nice to haves" - especially around UI / UX improvements that can feel like low hanging fruit but still take up valuable resource.
Tip: document all “nice to haves”, ready to be picked up should you get the resource. This helps people sleep at night, knowing all detail has been captured.
3. Approach the build in layers
Identify layers of functionality / complexity so that you can approach the build layer by layer, increasing in complexity as you go. This can mean faster and more accurate coding, as well as more frequent releases.
You need to be strategic in choosing the layers so that they amount to clusters of standalone functionality. To take a blunt example, if you were to build a car, you'd build the axle and wheels first to get a primitive go-cart, rather than build a seat, a wheel and a windscreen, which together give you no standalone functionality.
Ideally, you'd then be able to release these clusters in frequent iterations (see below).
Tip: theme your sprints according to these layers (e.g. "Sprint 1 - Axle", "Sprint 2 - Wheels", etc.) to help direct your project.
4. Discover in full before development
Make sure to fully map your software product end-to-end before you begin development (i.e. before "Sprint 0").
Discovery takes place before software development begins for real - it's the scoping and due diligence phase. During Discovery, you need to settle the team's vision for a user's end-to-end journey and any corresponding back-end asks. This can involve rough frames and diagrams, rather than a full-scale prototype.
Other key outputs of Discovery are "user stories" - enough to begin work on development in Sprints 1 and 2, and cover off the high level vision across the full end-to-end journey. (User stories are like pellets for a wood-burning oven. Each one articulates a functionality expected of the product. During a sprint cycle, a developer picks up a user story, works through it, and then turns to the next user story).
Comprehensive discovery can reduce cost. Discovery is cheapest at the start of a project when you are working with a slimmer team (usually just the SMEs, POs and, if you have the resource, a BA). You don't want to be pausing development once you have contracted expensive developers for late-stage discovery.
Of course, there may be times when you have no choice but to pause development to tackle something unexpected (e.g. a "technical spike") - we're only human.
5. Iterate and publish frequently
There's nothing better than getting into a rhythm of pushing completed work “live” at the end of every sprint cycle - it has many positive effects within the team and externally.
In doing so, the team gets into a habit of good housekeeping (e.g. testing, KBs and any other related protocols) to ease releases and maintain a regular communications cycle with stakeholders and sponsors.
The backlog for release stays manageable, and developers feels a dose of gamification in hitting release windows. There's a broader psychological advantage of regularly clearing the desks and seeing work go live.
6. Pilots can provide valuable feedback and build confidence
Good pilots can yield a few additional “must haves” and give the confidence to launch to your broader stakeholders.
I highly recommend piloting ahead of large releases. You can adjust variables such as the pilot's duration and participants to suit the product you are testing.
7. Scrum team members must perform their designated roles
The team and its members perform optimally when everyone is clear on their scope of responsibility and performing confidently within that.
A team can run into difficulty when people act outside of their remit and expertise. For example, a software developer might pitch in as a business analyst to craft user stories or refine the backlog. This can happen for a number of reasons (e.g. legacy expertise, confident characters, under-resource, etc,) and causes several issues (e.g. lack of clarity on responsibilities, disengagement, breakdown in team management, etc.).
The first step in combating this is to get clarity on responsibilities. Familiarize yourself with the roles and expertise of your scrum team members (i.e. POs, Scrum Masters, BAs, developers (front-end, back-end and full stack), and UI / UX) as well as SMEs, Sponsors and Stakeholders. You can workshop a RACI matrix (which stands for responsible, accountable, consulted and informed) to get a more detailed breakdown and engage the team.
Recognize when this issue develops, as it might be an important symptom of underlying issues.
Thanks for reading.