If you’re an in-house lawyer or GC thinking about how to improve your team’s legal operations – here’s one for you.
And from what we’ve seen, she’s absolutely nailing it.
So we just couldn’t resist the urge to pick her brains and ask if she’d share what she’s learned with you.
We’re so glad she said yes.
Lexoo: To kick things off, and for a little context, can you give us a very brief snapshot of your team e.g. how many members, structure, sits within the business or standalone etc?
Frances: I work in an integrated Legal, Risk & Compliance team: 2 lawyers and 2 risk and compliance specialists, all reporting to a General Manager, Risk & Compliance. We sit together in an open plan office that we share with the business.
OK great, before we dive into anything too technical, if you could explain Agile in a tweet (i.e. 140 characters) how would you do it?
Agile is a principles-based task management system that ensures I don't waste the present moment doing work which is not needed yet or at all.
I like it. So, how did you and your team prioritise work and manage projects before going Agile?
Like many others, we used a well-intentioned but ultimately imperfect set of lists. Individual to-do lists, collective to-do lists, takeaways from team meetings, Excel spreadsheets, Outlook 'tasks', Post-It notes...
… yeah, a lot folks in tech still swear by Post-It notes. How did you discover Agile and what got you into it?
Netwealth is an investment administration platform and is constantly working to improve user functionality, so software development is my client's bread and butter. Our IT teams have been organised into Scrum teams and using Agile to run their projects for a number of years. Some parts of the business have switched while others are still doing so, with different teams adopting different aspects that suit their respective functions.
OK let’s get into some nitty gritty, what does Agile look like for your team? E.g. do you use sprints? How long are they? How do you record them (any tools?) Do you use a points system? Standups?
Our version of Agile is bespoke. A software developer might use a less polite word! For our team, the anchoring concept is our task board, fondly known as "the Agile wall". We have plans to migrate to a software-based version — for now, we’re using an actual wall, printed labels and lots of Blu Tac. Our Agile wall captures the universe of tasks we need or want or hope to deliver to the business, from 'urgent' right through to 'wishlist'. Rather than create a user story for each task, I adopt the user story that has been articulated by the business, as I find this helps me ensure the end legal product or advice is fit for purpose. We do Kanban standups (team meetings at the wall), usually weekly. We have a weekly sprint cycle. While we have a target number of tasks completed per week, these are merely soft targets because task size varies and we don't assign effort ratings to our tasks. We sometimes vary the length of the sprint cycle when this will assist with our goals. Our current sprint runs through to 30 June, for example.
That’s brilliant. Loving your “Agile wall” by the way. Can you talk us through an actual example of how it works from start to finish (for a task/project)?
For each request that I can't complete immediately and quickly, I use a widely available Excel macro to generate and print a physical 'ticket' that represents my task. The ticket describes the work I need to do and also captures details such as instructing person, date requested, work type, and best guess at due date. Complex requests are unpacked into multiple tickets. Then, onto the Agile wall they all go. At the beginning of each week I select those tasks I plan to focus on for the week. I then prioritise within those. The Agile wall gets reviewed and updated throughout the week. The goal is to move each ticket across the wall from left ('backlog'), through the middle column ('this week's priorities') and over to the right ('completed'), within the required timeframe and yet not ahead of more urgent tasks. However, the process is rarely linear. Changed business priorities or deadlines are very normal, in which case a ticket might return to the backlog, or get binned, or a different ticket or new ticket may take priority. This reflects the reality that the workday often departs from the schedule.
You’re sounding more like a software developer by the second! Do you think Agile works for lawyers managing legal work as well as it does for developers pushing code?
Some of the obligations we have as legal professionals require careful handling. For example, the duty of confidentiality can be a poor fit with a highly visible Kanban. More fundamentally, though, Agile seeks to prevent non-urgent work from taking undue priority, whereas I suspect most legal clients would not appreciate being told their request is not yet important enough to be worthy of their lawyer's time and attention. This is why I regard Agile as a better natural fit for in-house teams than for private firms; all requests to Legal are ultimately in pursuit of the same strategic goals. That ticket which is struggling to progress out of the backlog is stalling there for the greater good!
Indeed, so what’s the biggest benefit you’ve seen from using Agile?
I see twin related benefits. The first is a detailed understanding of the business' need for legal services. Our records of done work capture data which can then feed into management decisions about hiring, or changing the way we use our external firms, for example. The second, more surprising benefit relates to team cohesion and morale. Each team member has a good sense of what everyone else is working on. Our system can handle very high volumes of requests, which was critical while I was the sole internal legal counsel. We can see chances to help each other, and we have early warning of duplication or timing issues. It is obvious when the distribution of work needs rethinking, and also when we deserve to celebrate!
OK final question, what tools/resources or tips would you give to other in-house counsel considering the Agile approach?
Agile need not be an ‘all or nothing’ proposition. The concept has been trendy in professional services contexts, but at the end of the day an Agile approach will only be sustainable if it actually works for the relevant team and delivers improved outcomes for the business. This is the case regardless of whether you’re an Agile expert using detailed software to apply a pure version of Agile, or whether you're a newcomer using Post-It Notes on the office fridge. Different aspects of the approach and different terminology will suit different teams, depending on factors such as team composition, work profile, stakeholder requirements, and relevant company policies. My team continues to refine its own version — an Agile approach to the Agile approach — which seems fitting. I warmly encourage lawyers who are curious about Agile to be courageous, find some blank wall space and dive in.