Adapting Agile for a new industry

The problem

Off the bat, I’m a big advocate of agile philosophy, particularly that of retrospectively looking at the process you’ve been following, the work you’ve been doing and how you’ve been doing it, and attempting to improve and build on it to get better at the process / job / life you live. I apply elements of it regularly in my day to day life, although if I get caught calling my wife a Product Owner (PO) again, she’s probably going to make me sleep on the sofa.

There are a lot of explanatory articles already out there that go into a lot of detail on the ins and outs of Agile (Scrum) and how it is supposed to work. An evangelical approach is usually equal parts “wouldn’t it be nice” and “it’s never really realistic”. I’m not going to dedicate time in this article explaining those details, but I’m going to touch on what we understood for them for the purposes of addressing the challenge we faced:

I work for a legal firm in the UK, and they have just started moving into the technology industry. They hired a couple of half decent developers (myself and one other) and allowed us to forge our own path with building an application which we hope can go to market at some point in 2020. We were quickly in agreement that we would use agile methods to try and keep ourselves on track, and gave the director a crash course in what it was (seeing as he was going to be the PO moving forward.)

The director was very impressed, and immediately started to muse:

I wonder if we could use some of these methods to improve the processes of our legal team?

Obviously as a big advocate of the methodology, and as someone with a few years experience, I believed we could. So we picked a team to be guinea pigs, got the lead on bored, and set off on trying to make Agile work for a legal department.

The easy wins

We jumped straight in with a “this is agile and it will revolutionise the way your team works!” Full of excitement to get started. We set up a ‘sprint planning’ meeting where we went to planning poker and estimated some story points for the first time, and dove into the first (weekly, moving to fortnightly after some practice) sprint without hesitation.

Some things went really well and are things I think pretty much any team on the planet would benefit from:

• Daily ‘stand ups’ — so called because they can be done stood around a water cooler (back when everyone actually went into an office and worked geographically close together). We approached these in much the same way the world of tech does, making it clear it’s not supposed to be a ‘blow by blow’ account of your whole day, but a broad strokes what you did, what your plan is today and (importantly) raising any blockers you have to your team lead. It didn’t take long for the team to get into the flow of stand ups (via zoom, for the moment), and everyone on the team has said they think it’s a brilliant addition to the routine.
• Retrospectives — The (IMO) most important ceremony of the agile scrum process. We started them off (via zoom, again) with ‘Mad, Glad and Sad’ to feed them slowly through the process. After some teething issues with regards to feeling open enough to chat about things in front of the lead (something that is just a given in the world of tech these days) we made some real progress and came up with action points to further improve the processes we were already adopting.

It wasn’t all plain sailing, and some things didn’t work out as well!

The teething issues — differences between tech and legal

One of the first things that I noticed during the sprint planning session was that the conversations would be a lot less of a group wide discussion and a lot more like a one to one with other people listening into the work being discussed. e.g.

“OK, Paul, your priority for the next sprint is to get the information required for this legal document, draft it, and send it back to the client”

“That makes sense, it’s a bit complicated because getting information 1, 2 and 3 is no problem but information 4 could take some time. I think for that reason it’s a little complex.”

“Shall we opt for a 3 instead of a 2 then?”

“Yeah I’m happy with that”

“Great, next priority for you to work on is…”

And the work was divvied up to ‘Paul’ in this instance until they agreed that was all the work he could do in the sprint, and then moved onto the next person.

There was a clear reason for this. Paul’s legal book of work was stuff he had already been working on, already established contacts with, and already knew the processes to follow. Similarly, he has / had no real idea about the intricacies of someone else’s work, aside from the broad strokes of what needed to be done. Contrast this to tech, where the team has a backlog determined by the PO and whoever is free picks up the next pressing issue, this was a lot more a case of “here is Paul’s work for the week, and here is Paula’s” (I’m not great at picking anonymous names).

This meant the first sprint planning had an awful lot of wasted time for those not really included (imagine being in a sprint planning for a team you had no part in!) and something we needed to resolve.

Another issue that raised its head was that, due to the nature of the beast, a lot more communication between parties goes on during stories and tasks in legal than in tech. Instead of (in the tech world) the PO asking for something, seeing it at the end of a sprint and then refining expectations, the story for a legal team could consist of multiple ‘wait points’ for emails to be returned on a piece of documentation or providing data. This was something that needed to be accounted for in the stand-ups, and resulted in a lot more blockers being raised with the team lead (who, for the purpose of ease, was acting as Scrum Master).

Getting past the problems

We decided to quickly drop the evangelical ‘pure Agile or bust’ (not that I believe anyone expected it to be the case, even from the off) and instead tried to cannibalise parts of the methodology into something that simply made the legal team work ‘better’.

In respect to the planning, we have adapted the setup so now everyone has a 15 minute chat with the team lead to discuss their priority and agree on the work they will accomplish that sprint. While it didn’t help the team leads time, it freed the team up more to get on with their work. After everyone is finished we dial back in, and each member gives a weekly standup “what they plan on getting on with” so everyone is still included in the loop but without the time spent losing attention listening to the detail of somebody else’s tasks.

For the blockers, and the back and forth elements, we introduced a new status to the flow. We now have “To do”, “In Progress”, “Awaiting Response” and “Done”. While the unidirectional target of the tasks is broken somewhat, it gives everyone a clear look at the state of play throughout the sprint.

So everything is golden?

Not yet! There are still issues and the team are very much still learning, as am I with how the process will best work for them. I particularly hope the retrospectives get better, as the team get more used to talking candidly about what went well and how everyone can improve. I think being in the office will help a little (no hiding or distractions when you’re in the room!) and I think time will tell. However I really feel already that the processes that have been adopted by the team have paid dividends and are helping productivity (albeit from a subject, zero idea what they’re talking about perspective). I’m hopeful we can bring more teams in to the leg-Agile methodology soon (patent pending).