The Agile LKE
As LKEs, we are working with developers, right at the intersection of technology and law. More than anyone else, we need to be prepared to interact with agile teams and adopt agile principles.
The big challenges for LKEs
Let’s face it, adapting to any new working practice comes with its challenges. Becoming agile is no different in that, at least.
Here are the top three challenges that we LKEs will face:
- Approaching project definition
With traditional (waterfall) projects, the spec handed to the developers would set out exactly what they had to do. No matter whether there was a better way, or that the proposed solution didn’t actually solve the problem – this was the job, and that is what they would do. Lawyers have tended to be comfortable with this approach because it gives them control of the project and allows them to put the work in up front.
In an Agile environment, however, this is turned on its head. The developers should be given a concept – a problem to be solved. They will then use their considerable expertise to work out the best way of fixing it. That solution will probably be quick and dirty, a proof of concept (or MVP), which they will add to iteratively. Rather than a full specification, we will provide user stories to help define the features we need. - Reconciling the differing approaches of our stakeholders
While agile is increasingly influencing working practices in the legal industry, it’s not there yet. Where it does exist, it is still naissant, and often has a very different form to that which exists with the developers. reconciling these differences has always been one of the great challenges for LKEs, and that seems set to get more complicated as we develop another version of the language that needs translating.
At least when these approaches, at least to technology, are accepted in the legal industry we will be on a similar page when it comes to definition of scope and iterative development. In the mean time, we will be working with legal teams that expect to interact with the technology in a very different way. This will mean persuading our legal teams not only to adopt the technology, but to adopt technology that is, by definition, unfinished. More than that, we will also need to persuade them to give it another go when new features are added. - Learning the language
Some elements of agile are a bit… cult like… I can’t think of a better word for it. Now, I am informed that this is intentional; apparently making the bosses worry that their dev team is a cult is a good way of ensuring they don’t come along to meetings (sorry, ‘rituals’)… I don’t know. What I do know is that, from the outside, the whole thing looks a bit too much like orgnaised religion for my liking.
I’m fairly certain that the chances of getting the legal industry on board is next to nil so long as agile sounds like a cult. So the good news is that, so long as we still sit primarily in legal, the fate of our immortal souls will remain for us to decide. However, the likelihood is that you’ll have to learn to decode their religion in order to get stuff done.
How to approach these challenges?
Agile is a reality for most dev teams at the moment. So, if you want to work with developers to get your tech built, it is worth getting yourself a basic understanding of agile principles and working practices. This will help you understand their needs and expectations in order that you can engage with them effectively.
Glossary of terms
Something preventing you from getting your job done.
Having all the people in the same space/location.
Note: the uninitiated call this ‘going to work’
One of the ‘rituals’: a quick team meeting where everyone working on the project updates the team on what they are working in, its status and any blockers that may be slowing them down.
Note: often participants are literally standing, usually away from their desks.
The big picture problem that we are looking to solve. User stories fit into and support the Epic.
Note: previously known as a problem statement
A thing that your thing can do or has.
Short for Minim Marketable Product. The minimum number of features required to get a product to market. At this point, you can start marketing your product. If you’re very lucky, this could be the same as your MVP, but most people aren’t that lucky.
Short for Minimum Viable Product. The minimum number of features required to do the thing you are aiming to do. It may not be pretty, it may not be perfect, but it functions.
Note: NOT most valuable player, as I have to remind myself every time I hear this.
A turn away from one concept in favour of another. This could be a concept, a priority, anything – a truly agile environment is not so dependant on any one thing that it couldn’t cope without it.
Note: this is a dirty word among those who have lived through the catastrophe of a premature pivot. Like ‘Brexit’.
Short for retrospective. One of the ‘rituals’, in which project team members will collectively look back on their work and share their opinions of what went well and what could be done better.
A blanket term for all the meetings that are routinely held by agile teams.
Note: it’s probably not really a cult…
A period of time during which work is done. Usually, but not always 2-3 weeks.
A description of a software feature from the perspective of a user. It will describe the type of user, what they want and why. These are sub-problems to help describe the core problem, solutions to which will be added as ‘features’.
Note: re-framing of the concept previously known as a ‘requirement’
An old, outdated project management methodology; the antithesis of Agile.
