Podcast Ep #121: Right Tool, Right Problem: Choosing Better Systems for Law Firm Operations with Robin Sims-Allen

John: It's understandable for leaders to want to reach for new tools or the latest techniques to solve problems in their business. But just because a tool is popular doesn't mean it's the right one for every situation. Along those lines, there are a lot of different methodologies out there that might be able to help you improve your law practice operations. But while some process improvement frameworks have proven themselves to be flexible enough to work in various situations, others have a much harder time adapting outside of their native environment.
​​​​​​​
My guest this week is a business consultant who has worked with a number of different tool sets in multiple industries. And I think her insights will help you get smarter about finding and using the right tool set for the problems you're trying to solve in your law practice.

You're listening to The Agile Attorney Podcast, powered by GreenLine. I'm John Grant, and it is my mission to help legal professionals of all kinds build practices that are profitable, sustainable, and scalable for themselves and the communities they serve. Ready to become a more Agile Attorney? Let's go.

A quick note. The concepts from today's episode should be useful to you no matter what kind of practice you're part of or what tools you use. If you'd like, stay tuned at the very end where I will briefly talk about how my software tool GreenLine supports the principles and practices from today's show.

Hey everyone, welcome back. This week I'm featuring an interview with Robin Sims-Allen. And this is another one of those episodes where I'm trying to bring in ideas and voices from outside the legal world to see what we can learn from their experience. And Robin is a certified Agile practitioner with process improvement experience using some pretty complex frameworks inside of large institutional organizations. And when she reached out to me to ask about coming on this podcast, it wasn't immediately clear whether she'd bring value to a legal audience.

​​​​​​​And also, I have to say, and I told her this directly, I was turned off at first by her pretty obviously AI-generated pitch. Which is too bad because I think the AI wound up masking her real experience and her authentic voice. But after a second email exchange, I was convinced that Robin's background in heavily regulated industries was at least worth a conversation. And I'm glad I reconsidered.

As you'll hear, Robin has some practical insight for how to navigate changing times in some pretty entrenched teams, including stints at software company UKG and Lockheed Martin. I think her approach is worth considering in our sometimes old school legal industry as well.

Before we get to the conversation though, I want to give you a quick decoder ring for some of the terminology Robin and I use because we're going to throw around a few industry terms that might be new to some of you.

I don't think I have to explain Agile overall or Kanban, or if you do need a refresher on that, go back and listen to the 101 series, but I talk about those plenty. Same goes for Lean and Lean Six Sigma. I've talked about them before and they're reasonably commonly understood. But high level, you're more likely to hear about Agile in technology companies and Lean in physical world places like manufacturing or logistics.

Now, Scrum is a specific Agile approach from the software world and it's probably the most commonly practiced Agile framework. It's built around short, fixed length work cycles called sprints. And usually they're two to four weeks and it can work well for dedicated teams on focused projects. But as I'll explain in our conversation, it tends to struggle in multi-project environments, which is what most legal teams have.

And then there's a thing called SAFe, which is an initialism for Scaled Agile Framework. And SAFe is essentially Scrum scaled up for large enterprises. We're talking hundreds or thousands of people, lots of different teams, complex dependencies. It's heavyweight by design and I think it's almost never the right fit for a law firm, but we'll talk about why.

And then finally, you'll hear us mention Waterfall, which is basically just traditional project management where you plan everything up front, work through a sequence of phases in order, and then usually don't revisit earlier decisions. And it has its place, but it's not very responsive when reality doesn't cooperate with your plan. Which in Robin's and my experience is most of the time.

All right, with that context in place, I kicked off the interview by asking Robin what are the sorts of problems that companies are coming to her to solve and what is she thinking about when she's trying to solve them?

Robin: So each organization pretty much has the exact same issue. They are either integrating legacy systems and merging them into one new system, or they are simply trying to do a process where they want to deliver more faster. So it may be a transformation of some type. And typically this transformation is organization-wide. They're trying to touch every entity in the business.

The issue that comes into place is during that process of this digital transformation, they have failed to realize one size or one framework does not fit the entire organization.

John: Ah, mm-hmm. So they're coming to you and I'm going to throw some lingo out because you and I talked a little bit before I started recording and this is lingo that I know that maybe not all my listeners know, but you brought up certainly Agile is one that comes up a lot. Lean, Lean Six Sigma. You mentioned SAFe, which is a Scaled Agile Framework, which gets into bigger implementations where you can't just do sort of Scrum on a single team. You got to like integrate a bunch of different things.

What are the things that people are really coming to you to ask about today? Like what's the flavor du jour of these digital transformations or frameworks they're trying to adopt?

Robin: So for the last four years, every organization that I've went to wanted to do SAFe. They wanted to beat the horn of SAFe. They want everything SAFe. Thing about Scaled Agile, it's very templated. You can't veer off the ranch. It's very prescriptive. There are certain processes and procedures that are in place together for a reason.

And what happens is with these organizations, they are trying to implement this very straight lace type of framework when their organization doesn't operate in that manner. And a lot of times they're operating in manners where it is Waterfall, which is another framework where you require all of these checks and balances, these guardrails, these handoffs, these signatures that you may need from a legal department or so forth before you even write a stitch of code.

And that doesn't necessarily work with Scaled Agile because you have to eliminate a lot of those checks and balances because it's already built into the framework itself.

John: It winds up being maybe, correct me if I'm wrong, but a question of there are feedback loops that need to happen. There are quality checks that need to happen. I think one of the notions around a Waterfall approach, which for those of you that don't know Waterfall, it's sort of the more traditional project management where you've got the Gantt charts and the milestones and everything is supposed to very naturally click into place.

But one of the knocks on Waterfall in the real world is that it's really easy to design an ideal state on paper. It's a lot harder to do it when you're actually building with real humans, real systems, real problems. And so it isn't a very responsive approach.

Scaled Agile, Agile in general is designed to be a responsive approach, but I think what I'm hearing from you is that this Scaled Agile framework has its own structure and maybe even a little bit of rigidity, but it's a different structure than these teams are used to in a Waterfall team.

Robin: Definitely. So in consideration with SAFe, what you want to consider is what types of implementation are you trying to do? Is this a value stream where you're focusing on a customer facing opportunity or is it something that is behind the scenes, like a data remediation team, or are they merging data? SAFe wouldn't work for those types of teams because you actually do need that Waterfall approach where you are having that centralized thinking with the higher-ups or whoever the owner is of that operation to sign off on this interaction.

You still want the feedback. You still want to fail fast if that's what you need to do. But at the same time, you shouldn't be trying to say, okay, well, let's do a cadence of planning work or let's do a cadence of holding these time block meetings. You know, some of those activities that occur in Scaled Agile, that makes sense when you're writing code and you are doing a customer facing opportunity where you are trying to deliver something or succeed at something in a two-week or a three-week or a four-week cadence.

But if you are working on data or some type of remediation behind the scenes, it doesn't make sense for you to try to time block it. So therefore it doesn't fit a Scaled Agile approach. Perhaps a Kanban approach, that's another framework. But a lot of times companies don't really want to embrace Kanban either.

And the reason for that is because it seems like it's too free-will thinking or too outside of the box or who's going to check what's happening and who's going to own this? You can still have owners in that particular structure, maybe by limiting how many activities are happening at the same time. Maybe organize your work on a Jira board or ADO or whatever your tool of choice is. You can still visualize that. That can still be present to leadership or whoever the owners are of that particular outcome.

But you shouldn't be trying to be a Scaled Agile because it just doesn't make sense. It doesn't make sense to do the quarterly planning because a lot of times when you're dealing with compliance, who's to say that you're going to get your sign-off from legal or compliance risk in a three-week or a three-month or a 10-week cadence? I've seen things where it can go over to legal and sit there six months or more.

John: Well, that's one of the problems I'm trying to help solve. But yes.

Robin: And if you're doing Scaled Agile, that's anti-Scaled Agile because it needs to be within a quarterly type of activity, whether it be a 10-week or a 12-week. We need to have something to say that it started and something that it ended. And you can't do that in something that requires several layers of handoffs or sign-offs.

John: Yeah. Well, so a few things about what you just said. Number one, you brought up Kanban and that's the one that is near and dear to my heart. I have found in doing this work with legal teams for over a decade now, that's the methodology that works best in most legal situations. And I think for some of the reasons you talked about, it gives you, to my mind, the right combination of certainty around certain compliance standards, right?

We try to build quality standards in. We've got these definitions of ready and definitions of done and these checkpoints and review points and all the things to make sure that number one, nothing is going out the door unless it actually has been validated for quality. But number two, we're trying to push those quality standards further and further upstream so that by the time it gets to the quality check phase of the work, we can be reasonably confident that it is going to pass muster at that point.

We're not making a diving catch at the end and in that place in my world where if it's a senior attorney or, you know, an experienced team member that's doing that quality review, we don't want to put them in the spot where they are up against a deadline.

The work product does not have sufficient quality and now they have to make a decision, should I push it back upstream because it failed my quality check and I should from a teaching and learning and feedback loop standpoint, I should make the person who gave it to me engage in the rework, but I don't have time to do that anymore because I'm up against a deadline. So now I have to do the rework and that winds up being a real source of frustration in practices.

And it's not to say we can avoid all frustration. Sometimes a little bit of that frustration is great because it's the thing that creates the impetus for improvement and change down the road. But I can see where you're going and in terms of Scaled Agile, which I think is loosely built around the structures of the Scrum methodology with sprints and feedback loops and all the rest.

​​​​​​​And I long ago, I have tried to implement Scrum in legal. It can work for teams that are relatively dedicated teams working on relatively big projects. So really complex litigation where that's really the main thing a team is working on, complex M&A deals.

But for the most part, most legal team members are working on many, many projects at once. You've probably heard like I have, one of the knocks on Scrum is that it doesn't perform as well in multi-project environments. And legal teams are often extreme multi-project environments. It's not unusual for a single lawyer to be involved in 20 or 50 or even 100 matters at once.

Robin: Definitely. And typically, when you think about the Scrum, it's time-boxed. It needs to be time-boxed in order for it to work. And if you have multiple things going on, just think about it in general speaking, just take it out of Agile in itself, you can't be thinking 100% about everything at the same time.

John: No, of course not.

Robin: It's just not possible. But one of the things that I specialize with with these companies that I work with is I identify the organization friction or the cultural friction because what I find is if we are all trying to strive towards one particular framework that doesn't necessarily work and it causes friction of some type, our developers, our product managers, our project managers, if they're having to be overburdened because they have to feel like they have to commit to everything because that's what SAFe says that you should do.

You have to commit to these items and you can't back out. Once you're in it, it's there and it's done. And there's no opportunity to reassess unless you fail. And then you have no choice but to reassess. But then that becomes friction. And then what happens is is now our developers are being overloaded. They're being context switching. They may have to work on one thing and then switch to something else and then back and forth. And then what happens is is nothing gets done.

Also, you may lose people because people, they want a mission. They want to stick with their mission from the start to the end. And if they're being pulled in 100 directions, nobody wants to do that.

John: I think what you're saying in this developer example is one of the challenges with any framework and any organization is how to number one, make sure that you are keeping good people, right? I think that's almost table stakes. The other piece of it though is how can we turn individual knowledge and individual wisdom into institutional knowledge, not that we want to have this turnover, but when we do have the turnover, it doesn't create these giant waves and troughs that we have to deal with.

In my world, right, that senior associate or that senior paralegal that was our number one estate administration paralegal and that's the person who knows all the forms and knows how to get the clients to get the information and they just walked out the door or they just retired or they won the lottery, whatever happens to be, we still need to be able to carry on as a business in general without maybe that one senior attorney or the owner who knows how to do it, but they're the one getting pulled in 15 different directions.

So what are your strategies for that? And then I want to come back and talk about timeboxing too.

Robin: So the key to what you just said is cross-functional. I don't believe in any environment, no matter what industry it is, there should not be a gatekeeper of knowledge. I think knowledge sharing opportunities for a lot of reasons, I'm not a big fan of meetings, but if we're going to have meetings, let's share this knowledge. Let's come to the table and actually collaborate. Let's solve problems together. That way we're all coming up with the solutions together versus us depending on this other person to come up with the solutions.

And if they so happen to leave the organization or they just so happen to go on vacation, we're screwed. So now that everyone has that same information and they have access to that information, so whether you keep thorough documentation or you have some AI information that's recording and building you a database behind the scenes where everybody can just type a keyword and find this nugget of information or you're doing these interactive webinars and sharing knowledge and just learning opportunities.

What makes Agile work is learning. That is the component about Agile that people miss. They figure, okay, let's structure, let's organize, let's take away centralized thinking and make it decentralized. Those are all components of that, but the key is learning and how we learn and how fast we learn.

John: Breaking in here to bridge a gap. Robin's point about knowledge sharing let us into a discussion around timeboxing, which is one of the core tools from Agile that I think works really well for legal work.

Robin: So timeboxing, I believe a lot of people overthink it. Timeboxing should be a beginning and an end. So whether you are saying that it's a two-week sprint, three-week sprint, or whether it's a 15-minute meeting, 20-minute meeting, 30-minute meeting, what it means is it started at a particular time and it ended at a particular time.

And what you want to do is respect that time. So whatever it is that you have allotted for this particular activity or whatever it is that you're trying to do, you need to start it and you need to end it, especially if it's a meeting and you said this meeting is 60 minutes, it better end in 60 minutes because that is what was agreed upon.

Nine out of 10 times, you have already provided what those discussion points would be in that particular meeting. And if you're finding yourself running over that time or that commitment, nine out of 10 times it was because you didn't fully think about what that meeting was about. And it was instead a brainstorming session or a let's just keep rambling until we walk ourselves out of a situation. And that shouldn't be the case. It's not a conversation. It is an activity. Again, it's supposed to lead to a decision at the end.

John: Yeah, I like that. And it is totally inbounds to say, look, we are going to have a generative discussion. We are going to have a brainstorming meeting, but we're going to have a brainstorming meeting for half an hour, 45 minutes, whatever it takes. And then we're going to respect everyone's time. We're going to create some deliverables, which is, great, all the ideas that came out of this meeting, I'm going to gather them together and then we're going to come back and we're going to vote on which are the top two that we came up with, or we're going to take some other action, right?

There's a place for generative discussion. It's not inherently bad. But the key thing to me, at least, about these timeboxes is there always needs to be a deliverable of some sort at the end of it. It can be really light in some ways, but to flip back over to my legal research, yes, we do as lawyers have a duty to really fully understand and unpack whatever the legal issue is at hand. But that doesn't mean we still can't use timeboxing.

So if we say, okay, I'm going to enter into a three-hour research deep work block or something for me personally or maybe with some other people and I'm going to spend that time trying to find and maybe it's AI-assisted, whatever happens to be, but I'm going to fully try to understand at least one or two cases that is relevant to my client's issue.

Either way, when that timer goes off at the end of the three hours or maybe at two hours and 45 minutes, I'm going to pause. I'm going to be intentional about writing down, what did I learn from this block? What did it tell me about my theory of the case? Did it help in favor of my client? Did I find stuff that was opposed to my client's position, whatever it happens to be.

And then what do I want to try to learn in the next time blocked research session that I'm going to do and really making sure that we're putting those intentional signposts along the way so that getting back to what you said about Agile, so that we are in a position of iterative learning and we're doing regular assessment and check-in and building in that feedback loop to say, what have we learned and also what else do we need to know?

Robin: And you know why that is? Because it's psychology behind it. Just in general, every human thinks the same way. They want to arrive at a reward of some nature. So when they have spent this time or that hour or so forth, they feel like they have accomplished something. And that's why it's important to timebox things.

For instance, even if you're not doing technology or anything, you should literally take those eight hours out of your day and timebox. Take your hour to look at your email. And what that means is really focus on the email for a full hour so that you're fully engaged, so you can fully devote yourself to that particular activity. And then once that hour is over with, move on. And what that allows you to do is to not only one, it allows your brain to reset and then is ready for the next activity, but it allows you to figure out what your reward is.

Hey, I was able to read 100 emails, or hey, I was able to respond to whatever it is that I needed to do. Or in your case, with the legal research, hey, I have some new information that I can share with my client, or I have discovered another situation that I need to be cognizant of for my next research. So it's psychology based at the end of the day because you still want to arrive at something at the end.

John: Yes, I love that. And it, again, the whole point is it's making you smarter and even if you're getting bad news, right? Maybe you're again, to torture my example, I'm doing research and case after case has got me shaking my head saying, boy, I can't find what I'm looking for. This is not a good thing for my client.

I want to know that now because if I got to break bad news to my client, I don't want them to have to keep investing their time and money. I don't want to have to be investing my time and energy in a losing case. And it's better to know that as early as you can possibly know that than to wait to the end of some long drawn out period before that comes to light.

Bridging another gap here. Robin's point about clients getting bad news early connected to something I've been talking about a lot lately, which is the importance of building regular feedback loops, not just within your team, but with your clients as well.

One of the things that I like about an Agile approach is that when you build in these consistent and regular feedback loops, and that can include client meetings or client check-ins. And certainly for the teams that I work with, I often suggest if they don't have this already, that they're doing at least monthly check-in meetings with every client on every matter that they have, even if it's what I call a no-update update, because at the end of the day, part of what people are hiring you for is navigation of these complex systems and understanding of the processes.

And some of these processes take a while. Legal process is not fast by design. We call it due process and we slow it down for a reason. But that doesn't mean that the client doesn't want it to be moving faster. So I think one of the hallmarks of an Agile approach is that we're going to put these feedback loops on a cadence and we're going to honor that cadence, which is a form of a timebox, no matter what, because we're going to have learning that goes either way.

And maybe we learn that our client simply cannot handle the stress of living with this legal cloud and even though things are moving from your perspective, it's moving too slow for them and we need to be pushing towards a settlement, any number of things could be happening.

Robin: Well, that's why transparency is important, whether it's Agile or in any profession. You want to be transparent. People respect over-information. Overload them with information. So if you're doing legal work, you probably already know what those feelings or those questions, because you've heard them before. You've had them with your clients. So being proactive and just overexplain the process.

Hey, typically this particular case is going to take one to two years. That way people can start building it up and they’re okay, one to two years. Okay, I just got to make it one or two years. So because it was transparent from the beginning, whereas someone telling them, oh, well, we're going to work through the process. We're going to get there.

I can't do anything with that information. I need to know a time frame or something so that I can have something to go or reference at a different time. And I think that's where transparency comes into place. And that's very important in Agile. You have to be realistic in your estimations when you're estimating complexities or estimating when something is going to be delivered.

You have to be transparent because the more you try to hide with numbers and data and metrics and OKRs, KPIs, and you're just hiding under all of those things, it makes the story even more complicated, which causes more friction, which causes more confusion, which causes disconnection, which means you have failed Agile in any other activity that you're trying to do.

John: I love that. And for me, that ties all the way back to something you started with at the top, which is there is no one framework for problem solving, for process improvement, for project management, for legal matter management that is going to work 100% of the time in all situations for all teams for all businesses.

And so, I'd love to sort of maybe end on your approach to using different tool sets, different tools in your toolbox, teaching different tools to the clients that you have, so that we're really saying, okay, these problems that you're solving, there are good solutions to them, but if we get too dogmatic about any one particular way of working, we're going to start losing sight of the forest for the trees.

Robin: Definitely. So the strategy is to before any activity, you want to observe. Don't make any action. I think a lot of times that's the part that makes companies or organizations uncomfortable is really taking that time to assess what is happening, assess what the current state is, and then map what you would like the future state to be.

I think each framework that they're committing to, they're looking at future state and that's it.
That's all they're worried about is future state. They do not know what current state is until they get into the weeds and find out that they should have been going one way and they're going the wrong way. I think people need to get comfortable with being uncomfortable and taking that time to really observe what is going on.

John: Yeah, I love that. And you actually unlocked a little bit of an epiphany for me, which is because I see a lot of times working with again, legal teams and law firms that they can be a little impatient in terms of the process improvement work, the transformational work, like we want to get to this better state quickly.

And increasingly today, the manifestation of that is we're jumping into these AI tools really, really quickly because of the promises that they're making, but maybe without doing what lawyers already know how to do in the context of their client work, which is to take that step back, do the assessment, build the case, understand the prior case law, the facts of the case, the data, if it
applies.

And so maybe what I'm hearing from you translated into the legal world is we need to be a little bit more patient and respectful of the process when we're working on our on-the-business projects as we would be when we're doing our cases on behalf of our clients.

Robin: Yes, that's exactly what I'm saying.

John: Love it. Well, Robin, thank you so much for coming on and sharing your perspective about the sort of process improvement, Agile world outside of legal. I think it's just always useful for me, of course, and hopefully it's useful for my listeners to be able to know, number one, you're not alone. We're all having these types of problems in all kinds of industries. There's some very human things that come up into play.

And number two, there are ways of working that are just better. None of them's perfect, but if you're intentional and again, observant, I think is part of what you're saying, then we will figure out what the problems that need solving and we will figure out the right way to get them solved.

Robin: With a conclusion one way or another.

John: Love it. All right. Well, thank you so much and we'll talk again soon.

So when it comes to adopting an Agile approach to improving your law practice, there are a lot of legal technology tools out there that have borrowed bits and pieces from Agile. You'll see a lot of cards and columns that look like a Kanban board. And of course, the software developers behind the tools are almost always using some version of Scrum or Kanban to manage their own work. But what I bet you won't see is a technology team using their actual legal technology to manage their Agile workloads. That's because the tools they're building aren't truly Agile.

And once you start adopting Agile practices, there is a big difference between a tool that looks Agile and a tool that actually supports your firm in developing the habits and the maturity that continue to drive improvements over time. GreenLine is different. For one, we're using our own tool to manage our whole business, from building software features to scheduling demos to managing our marketing content calendar. It makes sense because my co-founders and I all have deep experience as Agile coaches and practitioners.

And for Jeff, he's using it to manage work in his law practice as well. So when you use GreenLine, you're not just getting a prettier interface that is the flavor of the day. You're getting a tool that was designed from the ground up to reinforce the right habits, things like limiting your concurrent work, building in quality standards, and centralizing and streamlining your matter-level or project-level communications.

GreenLine makes it so everyone on the team can see intuitively where every matter stands and what needs to be done to move it forward. If that sounds like something your practice could use, I would love to show you more. Head on over to greenline.legal and look for the book a demo button to set up a time to talk.

All right, that's it for this week. Thank you again to Robin Sims-Allen for joining me today and I will put her contact information in the show notes. If you have any questions about the things we discussed or want to hear me address a specific topic on the show, please let me know by shooting me an email at john.grant@greenline.legal. And if you find this podcast useful, I would love it if you could rate or review the show in Apple Podcasts, Spotify, or on YouTube.

As always, this podcast gets production support from the fantastic team at Digital Freedom Productions, and our theme music is “Hello” by Lunareh. Thanks for listening, and I will catch you again next week.