Agile in a legal world, did it work?
About four months ago our company (made up of a burgeoning tech department and an already successful legal department) decided to cannibalise some bits of the agile methodology from the software world and try to apply it in a legal framework, in an attempt to streamline, optimise and improve the processes of the day-to-day workings of one of the teams, chosen to be guinea pigs.
It’s been a third of a year and I thought I would jot down a few things I’ve learned personally from running this experiment, and what I hope will happen moving forward in the company.
Disclaimer: I’m a huge proponent of lots of pieces of “Agile” and regularly exhort the importance of retrospectives, due diligence in planning and backlog refinement. We use it in the current team I’m running, and it keeps everyone (from the developers through to the PO — who also happens to be a director of the company!) happily pointing in the same direction. Hence I was already biased and determined to make this work!
Let’s start with planning
This element of Agile, which is usually crucial for a team to keep pulling together in the correct direction, and to tweak what that direction is, was certainly the hardest element to shoehorn into the legal working world. Each team member has clients, and each client has work pending. It simply isn’t feasible (as it usually is in software development) to prioritise everything and let the next free person pick the top of the list. They all have their own lists, and they all need prioritising individually.
To fix this we modified planning to be more of a brief, one on one chat with the team lead (yours truly sat in to make sure it was still conversational rather than “do this, then this, then this. Now go away” — not that the team lead is like that at all!) where priorities were discussed, and the order of work and volume of work agreed between the two members. This was typically a short (less than 15 minute) conversation repeated over the entire team.
The pros of this were that the members of the team weren’t listening to items completely irrelevant to themselves. The cons meant that the team lead had a longer amount of time spent than maybe a conventional product owner would do so to get all the sprints work sorted.
I’ve since taken a step back from the planning. I believe it’s still happening in some form, but I think it’s adapted to more of a Kanban style — adding things as they come up to keep a comprehensive list of prioritised tasks for each member.
Daily stand up, anyone?
Originally the team took to the daily stand up quite well, a chance to list off tasks complete, tasks pending and any blockers. Due to naivety on the team’s part (and a scrum master — yours truly — being too lax in not cutting people off) the stand-up times started to drag on, and people were getting frustrated at listening for up to 15 minutes when there was, really, nothing of import to mention. This falls back into the issue of each team member essentially being their own ‘mini-scrum’ team.
After a bit of reflection, we modified the stand-up somewhat, and simply asked for ‘any blockers?’ Since then, I believe the stand-up has returned to a short amount of time which is valuable to keep people engaged. Again, I’ve tried to take a step away and let the team handle the processes themselves, so I can’t say for certain that they still operate the way they did. They seemed to be working well though!
And the big one — Retrospectives
If you’ve read anything I’ve written elsewhere on here (and if you haven’t, you’re missing out on dad jokes, nuggets of tech wisdom and me moaning about being unfit!), you will know that the biggest positive I take from agile comes from the chance to reflect, look back and improve. Which is what the retrospective provides.
This has been the hardest nut to crack with the team, and I believe that’s because it has the potential to be the biggest ‘game changer’ moving forward. Balancing between moaning about process that can’t be improved and focussing on what the team can attempt to improve has been a more difficult tightrope to walk than anything I’ve experienced in tech, and I believe that is more to do with the way the legal team needs to abide by a lot of processes within the client they are working for (in hindsight, it’s brilliant how much autonomy tech teams, even working for a contracting client, actually have).
We are making improvements every time, with regular reminders as to the purpose of the retrospective, and the importance of it. There are similar (but not the same) processes inside the legal team, so attempting to ensure that the retro doesn’t feel like a repeated meeting with no extra value is a constant challenge. However, I feel like the team have taken to it well, and the team lead has reported back to me that they truly believe the adaption of the retrospective has helped sharpen the team to be more efficient. Which, at the end of the day, is the ultimate goal, isn’t it?
So, was it a success?
I would like to say it was! I think we (including myself in that) have learned a lot, with regards to applying agile to a different framework. The teething issues we’ve seen in the team will hopefully not be repeated, and I would like to think it’s been a good enough investment in time to warrant extending the idea to the rest of the legal teams at the company.
‘Tech world’ agile didn’t just ‘slot’ into legal, as I initially, naively, thought it would. But with some tweaks here and there we ended up with a framework for discussion that kept the essence of self-improvement and optimisation.
The autonomy of agile was something alien to the team but I witnessed team members getting more confident at calling out their team lead and suggesting alternatives, something I really enjoyed seeing.
(and here’s hoping the boss reads this one and lets us expand to another team or two!)
