3.2. Responsibilities

Attorneys are subject to professional regulations. When organising your work in accordance with these regulations you need to consider deadlines, formal requirements, a content review of legal documents, and much more.

Agile work can lead to a setup where supervision is felt less as supervision but more like part of a natural collaboration. It makes the status of work more transparent, automatically showing where jobs are delayed and, to a certain degree, issues occur. That way, the attorney responsible can intervene where necessary. Due to the high-risk nature of an attorney’s work, being able to show you fulfilled your obligations is a crucial part of the work in a law firm. This includes activities from instructing your employees to explaining the risks to your client. Documenting this in a way sufficient for supervisory bodies such as the bar association, the attorney’s liability insurance, for potential court cases, and documenting advice to clients is not trivial. In the Agile process, these statutory requirements can be accommodated, as well as the needs of the clients. In subsequent chapters, you will see that the clients’ needs can be described as clear requirements for the case: the description of the work, the sequence of work steps and the checks done when changing status can be retained if needed for such documentation.

The laws and rules of professional conduct that apply to attorneys often state that the attorney is liable towards the client for all the work that goes out of the law firm and therefore needs to check the work of the team, which would not be necessary in Agile work in many other industries. This means as an attorney you may need to implement mechanisms to control the work results and check every piece of work that is going out. This is best achieved by introducing clear checks. In our opinion, Agile can help you implement these procedures because it helps to get better organised.

A pragmatic approach can be to assign the Product Owner Role to the attorney responsible, who can thereby directly influence the team’s work. Additional tools can further complement the work, e.g. checklists and standards that other team members can leverage to prepare their work. We will later explain tools and methods that you can leverage to implement this (Chapter 4 et seq.).

Practice Tip: Where to start?

There is no right or wrong regarding that question. But we recommend the easiest approach is if you choose a non-critical project to start with, maybe even an internal one. That does not mean a client project might not work well too, as we have seen with the case described in our story. In the end, you should choose a topic that is either low risk or you are so profi cient in that you are comfortable with handling it in a new working mode.

Story

Of Responsibilities and taking ownership

Whilst the team has decided on the frequency of the iterations, this does not answer how the parts join together and interact. Do Responsibilities change over the course of a project and who decides when a product is fi nished? They will soon learn more, but given the reputation of their fi rm, they certainly want to ensure one thing: that the quality is kept high; they will not compromise on that. For that reason, they fi rst want to understand how quality assurance can be implemented and how that interacts with Roles, Responsibilities, and Accountabilities.

A simple setup should be sufficient to start with. They try to implement only a few Roles, especially as they are a small team. If the methods are a match to their work, they can build on that. Alice is the person to do the last review of any given deliverable, because as an attorney and partner she is liable towards the client, which is why she was made Product Owner. That seems to be a good start, though they do know that they will need further parts of the process: from clarifi cation of what needs to be done, to distribution of work, meetings, and a clear way to implement the needed transparency. But they need to start somehow, don’t they?

Besides clarifying that they want to take it one step at a time, Fiona feels it is important to expressly state that whilst Alice is the Product Owner and thus the ultimate decision-maker on when the work is finished, that this should not limit the team’s responsibility regarding the work they take on. Her teammates concur, and Gabriel, as the junior associate, notes that in time he also wants to take the driver’s seat himself, leveraging his colleagues’ experience in feedback cycles. Alice expresses her motivation to empower her team more.