These days you can easily get the impression that “Agile” is a buzzword that has little to do with the Agile methodology and principles as they are known, especially in software development. When taken out of context, Agile is often misunderstood to be anarchy and planless, aimless working. This is far from the truth. In software development, Agile has proven to be a valuable system to organise work in contexts where the outcome and the way to the Goal are not clear from the outset. Due to this uncertainty, the frameworks used to get there needed to be even more well-defined. Many of these principles don’t seem to be applicable for law firms, yet we want to show you what you can learn from them and how you can use them in your firm. This also means that we will, at times, tweak the Agile standards and methods to fit better into the workings of a law firm, rather than following them to the letter.

In addition to giving you handy tools to implement in your daily working life, we want to show how Agile can improve your work, both internally and what you deliver to your client.

Some of the aspects that can be improved with Agile are:

• Transparency (e.g. clear requirements for your associates)

• Communication (e.g. clearly defined meetings with a clear outcome)

• Quality (e.g. clearly documented standards)

• Productivity (e.g. defined and standardised workflows)

This workbook is intended as an easy starter for you to implement your first Agile working setup, irrespective of your previous knowledge of Agile or project management in general. We will guide you through an Agile setup containing all the essentials but will strive to keep it to that and not to open advanced topics.

In this workbook, we won’t teach you how to use all the Agile frameworks in detail, but rather what the core ideas and principles are and how you can use them to improve the work in your law firm as well as collaboration between you and your client.

This means that you don’t need to implement all the tools we present and describe in this book, but we strongly recommend that you try them out to see how and when they can work for you.

Agile working setups differ between organizations. This book can apply to all shapes and sizes of law firms—from solopreneurs to big law, generalist to boutique.

It is also okay to tweak the tools you find here but beware that this can quickly lead to re-labelling of existing working methods. That said, you can, in our view, decide to adopt only parts of the setup we describe. When you choose to adopt a tool, you may change details to make it fit. We strongly suggest that you experiment with the contents of this book and try to fi gure out how it can be applied in your context. If needed, you can always consult with an Agile expert to support you in doing so.

The key question is: is there something to learn? After all, Agile at its core is an empirical approach. You have to learn about the work on the go, because you are not able to fully understand it right at the start. This also means improving your approach at hand and the team’s interaction as you progress.

Sometimes this question is phrased differently: is the thing we are trying to do complex? Are there unknowns? The answers to all these questions are highly dependent on the context. The same problem can be perceived as highly complex, with lots of opportunities for learning in one organization, whilst in another (perhaps one with a lot more experience in dealing with similar problems) it is merely a complicated issue with a clear solution. You cannot answer the question of whether an Agile approach is useful just by looking at the problem alone. You need to consider the problem within its specific context!

There are topics for which a standard process might be more suitable than an Agile approach, e.g. working with a public procurement procedure, but even then, some tools we show here can come in handy, as you’ll see later in the book. Where there is no benefit to gain from an iterative process, for parts that just need execution, having a standardized process can be a reasonable choice. However, some of the tools we show in this book—most notably Kanban (Chapter 5)— can be used in either setting, or for providing a more general organisational standardisation.

So how does Agile working intend to deal with such a complex situation? One key concept in Agile is radical transparency. The idea behind this is that by creating as much transparency as possible, it is easier to get new information and maximize learning. This means involving anybody who has something useful to contribute, sharing the current situation, and assessing and adapting as fast as possible. To make this work as smooth as possible, a lot of well-organized communication is essential. All this aims at ensuring the best possible quality and effectiveness (= doing the right thing).

One of the things that might be challenging at first is the concept of structured and, in parts, formalized communication. Agile working tries to produce clarity through well-defined processes and a structured setup of meetings. This might seem like additional work, but in the right context it is essential to ensure that a team works on the right things. Overall, it aims to ensure that resources are used as effectively as possible. To summarize: Agile is all about getting the most value, as quickly as possible.

Introduction

Law Firm Operations deals with the operational processes in law firms and how these can be optimized. The initiative aims to promote expert exchange, projects and publications. In exchanging best practices, connecting with experts and peers we want to share knowledge and drive innovation in law firms.

Together, people, processes and technology form the three pillars of digital transformation in law firms. They enable a more efficient and effective work enviornment that is capable of adapting to the constantly changing demands and challenges of modern society.

Whether you're a partner in a big firm or just starting out, this forum is the perfect opportunity to stay ahead of the curve and drive the digital transformation in your law firm and beyond.

Content

Join our newsletter

License

LLI Library

Cover Image

The Cover Image was generated by

• Law firms (from solo practitioners to big law) who want to work more in a collaborative and transparent manner, in particular:

  • attorneys

  • law firm managers

  • legal staff

  • administrative staff

  • Marketing and Business

  • Development teams

• All people in law firms who could potentially work in an Agile manner (including for small projects)

• Clients who want to work with their attorneys in an Agile environment.

This workbook will lead you through a simple Agile setup one topic at a time. The topics have low interdependencies, but we sometimes refer to explanations given in earlier topics. The workbook starts with the people and deals with culture, communication, and stakeholders (Chapter 2). The next chapter describes the general process of Agile working (Chapter 3). Next, you will work through the Elements used and how they are structured and defined (Chapter 4). Then, the very useful tool of the Kanban board is introduced (Chapter 5) before we conclude with the Agile meeting cadence (Chapter 6), author bios, and a glossary. The chapters will first introduce the topic, then provide examples and templates. Spanning across the whole book, the case of a litigation project shows the practical applicability of these methods.

We advise working through this workbook topic by topic in the presented order and strongly encourage you to use the templates and apply them to your own organization and projects.

While many of the steps can be implemented using digital technology, we will not discuss software or tools. In our experience, the tool should follow your specific needs, and we thus recommend to first work with a very simple setup to experiment with the application and only then introduce one of the many digital tools.

At the end of each chapter, you can see how the story of our case study progresses, and we provide you with a filled-out version of the template for our story and its example case. Using a case with a law firm, client and counterparty helps to show the different people that might be involved, though in practice the project might just involve the attorney and the client or be an internal law-firm project.

Many of the tools revolve around multiple team members, but they can also be useful for a solo attorney. They might help to clarify the processes in the law firm, get to know the client better and, in some cases, the attorney might also be on the client’s team in a project. In any case, we believe Kanban (Chapter 5) to be a great tool to organise your work, from one person to many.

When trying these things out within a larger law firm you might want to start with just one team or one practice group. In that case, try to make sure that the group of people who want to try something new have enough autonomy within the organisation to freely decide how they want to organise themselves. It is wise to have formal authority on board as well. Just be aware that establishing new ways of working in one area might be a source of friction with the rest of the organisation.

The templates build on each other following the course of the story, but you can also use them independently to gain more insight into a specific topic—for example establishing (one or more) law-firm-wide Definition(s) of Done (Chapter 4.8), to have consistent quality.

Each template can be filled out in this book directly or accessed through the respective QR code and filled out digitally or printed out. An overview of all templates, as well as FAQ and further information can be found here:

1st Edition

by Josia Splitt, Katharina Bisset, Baltasar Cevc (Authors)

with contributions by Isabelle Creutzburg, Martina Hackl, Kai Jacob, Anita Lamprecht, Jonathan Lourie, Jutta Löwe, Julia Luksan, Rainer Markfort, Esther Sowka-Hold.

License Note

This book is published under a Creative Commons CC-BY-ND-SA 4.0 License.

Text: © 2023-2024 Josia Splitt, Katharina Bisset, Baltasar Cevc

Graphics © 2023-2024 Katharina Bisset

Before getting started right away with Agile methodology, it is important to understand some key differentiations that are usually made when working Agile. One of these differentiations is aimed directly at how Accountabilities are constructed. It is the clear differentiation of WHAT is done and HOW it is done.

With this book, you will not take your journey alone. Alice and her team will accompany you, or rather, you’ll accompany them. We will describe their journey through a litigation procedure, which is set up using the Agile toolbox for their first time. We have chosen this story because most attorneys will know how a court case functions and can therefore draw their conclusions out of the litigation team’s experiences. The methodology can be applied in various settings (e.g. M&A deals, complex contracts, juggling a multitude of different requirements), but it might be easiest to start using a setting with few deadlines and outer requirements when you implement it in your firm.

Story

Alice meets Bob

Alice is an attorney and partner in the law firm Lawyering & Co. LLP, one of the renowned litigation firms in Newcity. She heads the firm’s litigation group and is known as a respected trial attorney. She has a team she highly values, all people without whom she could not imagine successfully leading the case. She has noticed that they often wait for her input, which is wasting valuable potential in her opinion, so she wonders how to involve them better in the planning stage, especially in more complex cases. Her core team consists of three people, with a few other colleagues she often involves. Fiona is a senior associate who has years of experience and leads a few mandates herself, while Gabriel is relatively fresh from law school but has previously worked for several years as a carpenter and only later decided to study law. Not to forget Oliver, who is the team’s assistant and very valuable as he is adept in keeping an overview of all the detailed puzzle pieces needed for the case. Then there is Igor, the IT expert who often helps them out with small automations. Alice would love to enable her colleagues in the team to work somewhat more independently of her, while maintaining their high quality outputs and personally keeping in the loop with them, knowing what they are working on and why.

Today is an important date, as Alice is expecting a visit from a potential new client. They have contacted her for help on a mid-sized litigation, but she expects that this might turn into a long-term business relationship. The person who will visit is Bob, boss of an equally mid-sized general contractor in the construction business, one of the more renowned companies in the area. They have an issue with one of their subcontractors, an electric installation company, for an office building they worked on in their city.

Alice, Fiona, and Gabriel go to the meeting room, where they greet Bob and the project manager of the specific building project, Caleb. After a round or introductions, they start discussing the case which has brought Bob to their office.

Bob’s company, Horizontal Builders Ltd., has been contracted to build the new headquarters of a small, up-and-coming company, to provide a sleek, modern, environmentally friendly building in a newly built district of the city. As a general contractor, Horizontal Builders is responsible for contracting all relevant crafts, coordinating the work and keeping the build quality high. As they are experienced, they chose reliable contract partners but due to availability constraints they had to engage a new electrical installation company, Eric’s Electro Builders, which proved not to meet the high standards Horizontal Builders usually set. The electrical works have been delayed and, while being in line with what is required in many parts, they do deviate from the required standards in significant places. Caleb estimated an overall damage of 100,000 Euro, maybe a little less if Eric can correct the deviations within a short period of time. At the time of the meeting, they cannot yet say whether that will be the case.

As usual, Alice not only asks Bob to detail the relevant facts of the case, but she is also keen to understand his business standpoint and understand what the key expectations are. For example, she wants to know how aggressive the litigation will be, what is important to other stakeholders and how closely Bob would like to collaborate with the law office. To her delight, Bob quite exactly matches what she likes best in a client: he wants to follow his rights while keeping a fair and partnership-based attitude. That is to say that he is open to settlements and to finding flexible solutions that also work for the counterparty. He and Caleb seem very flexible as to how they and the law firm collaborate for as long as necessary.

Bob, as he already expected based on the recommendations he received, is impressed by the attitude and business acumen the team shows and confirms that he wants to pursue this relationship.

Alice has been giving some thought to an Agile book she recently read and wonders whether this might be a good case to try it out on. She considers the key decision points on whether to go Agile, noting that the Agile methodology specifically makes sense where work has unknowns. That seems to be a good fit for this case, which will likely go to litigation but has quite a few unknows with the required proofs Bob’s company would need to bring and the big unknown of whether and how this could potentially be settled. She remembers the notes about transparency in the discussion and asks herself whether that might even help move towards a more independent way of working with her collaborators. She thus decides to give Agile a try for this case and informs her colleagues in the next team meeting, inviting them to share their views and to note their experiences throughout the process but also to note any criticism. In the team meeting they discuss whether it is wise to give a new methodology a try with a new client; while it evidently bears a risk that a new client comes in contact with a process that is not well established, they resolve that it is likely nevertheless the best choice to try it here. The case seems a good fit and it is easier to introduce a new process where none is established yet.

Overview of the people involved: In the law firm, Lawyering & Co. LLP:

• Alice: partner, attorney, litigation

• Fiona: senior associate

• Gabriel: junior associate (with practical background)

• Igor: IT specialist

• Oliver: the team’s assistant and magician for all office and file-related questions

From the client, Horizontal Builders Ltd. (~200 million EUR turnover, general contractor):

• Bob, the CEO

• Caleb, project manager

The counterparty, Eric’s Electro Builders (6-person overall, electro-installation company, incl. 2 apprentices and 1 office administrator):

• Eric, owner of the company, electrician

Further participants

• Sara, a friend of Gabriel’s who is a project management methodology savvy IT management consultant working for the top-tier consulting firm.

Every team needs some form of orientation regarding the content of their work and associated goals. This Accountability of providing the overall guidance for the team regarding where they need to go usually falls to someone called a Product Owner. The Product Owner is responsible for maximizing the value that the team delivers. But how does one do that? To start at the beginning, a Product Owner should communicate a clear goal to the team. This of course means that he/she needs a good understanding of the wants and needs of customers/clients and other stakeholders to be able to prioritize accordingly. In simple terms: the Product Owner is accountable for making sure the team goes in the right direction. Virtually any Agile framework has a function like this, although it is not always named Product Owner.

In a team where there are different subject-matter experts (e.g. a tax attorney, a corporate attorney and a contract specialist for a due diligence), the Product Owner does not need to be specialized in all the skills needed. It is their job to prioritise the tasks, to get the most value for the client/customer, and, if needed, defer to the experts on the team for technical (or legal) questions.

As attorneys, we don’t generally see ourselves as producers of a “product”, and even though this has become more of a topic with the emergence of new law firm business models, don’t let the term deter you. Think of the “product” as the service, the work product, and outcome you want to deliver to your client.

When talking about Agile culture, it is usually referred to as a set of shared values, principles, and behaviours as well as certain practices. A good point to start is the Agile manifesto1, with its description of the core principles such as the following, which are particularly relevant for our workbook:

• Individuals and interaction over processes and tools

• Limiting work in process

• Self-organization

• Continuous and incremental delivery

So how can an Agile culture be created? Isn’t culture per definition something that cannot be changed directly? At least that’s something that we hear at every corner: “You can’t change culture directly. It is too complex for that.”

The good news is that we are not that powerless after all. Culture can be changed—somewhat directly even. Of course, social systems are complex in nature and therefore a mechanistic approach will fail. In complex systems mono-causal explanations don’t work. Changing a culture is not as linear as modifying a machine. However, there are things that can be done to influence the behaviour of people within an organization. After all, we can change the framework conditions within which culture emerges. Changing these conditions requires working on the formal side of an organisation. This can take different forms. Examples could be to introduce new processes or establishing new pathways for communication. Setting up new/different roles could also be an example of this. In a law firm, frameworks that can be changed to cause a culture change are new systems for revenue and bonus sharing or new commercial models (e.g. value pricing).

The informal side of an organization (=culture) will react to changes on the formal side. So, after changing something on the formal side, we need to observe what emerges. From this we can learn more about how our system reacts and deepen our understanding of how we can change it.

It seems impossible to talk about Agile culture without mentioning the infamous Agile mind- set. We won’t go into too much detail here, but there are a few things to consider. First and foremost, consider your wording carefully. People generally don’t appreciate it if someone wants to mess around in their heads. So, talking about how you want to change their mindset can produce a good amount of resistance against whatever you are trying to achieve. Instead of trying to change people’s core beliefs, try aiming at observable behaviour. After all, what someone’s values and core beliefs are is not that relevant if the results are there. In other words: start with providing a frame for desirable (observable) behaviour and an Agile mindset can follow. Or not. It’s not necessarily relevant. What’s relevant is that things work, and value is delivered.

Story

Our team groups itself

Alice’s idea to make her team more independent of her as an attorney is indeed a match—self- organization is a key principle in Agile work.

It was the right decision to give Agile a try with a distinct project, a medium-sized matter in this case. They will not be able to change the whole law firm in one go and this project seems to have features that are a fit for Agile. That said, if they determine it is not working, they could still go back to their standard way of working.

Now that Alice, our partner in the firm, has decided to work in an Agile manner, she needs to set up the team. It is evident that the Agile team will consist of herself and her associates: Fiona and Gabriel. However, she’ll need to decide whether Igor as the IT specialist will be part of the team or someone they might just selectively ask for help. Similarly, on the client’s side, Bob and Caleb might or might not be part of the team. Later that evening, this starts to trouble Alice as she has no experience and no answers. The next morning, she decides that she will share her open questions with the team, so they know the reason for the delay in the setup. About two hours after their team meeting, Gabriel comes into her office and asks her whether she would be okay for him to openly discuss the matter, which she is. He has come up with a suggestion for the team setup, which Alice is curious about. It turns out that Fiona and Gabriel had discussed the matter and have found they share a very similar feeling: try it out with a small team, i.e. a core group consisting of the three of them. After hearing the argument, Alice concurs and decides they will go for a small team for this project.

Legal business and professional regulations obviously differ from software development, the industry in which the Agile methodology was developed. Due to that, an adapted version of Agile working methods is required to fit the legal sector. The good news is that this is indeed possible with relatively small changes. We see two topics that need to be addressed in regarding Roles and Responsibilities.

Firstly, many jurisdictions’ regulations require the attorney who is a member of the bar associa- tion to be liable towards third parties and have the oversight and control over the work that the firm delivers, sometimes to the extent that the attorney needs to implement controls in all areas of the firm. To mirror that, we suggest that the attorney responsible should take the Role of a Product Owner in the Agile setup. This makes it easy to keep the final decision with them. Big projects at a firm with many attorneys will sometimes have attorneys responsible for certain areas of expertise. In such settings, in general, each of them will take on the Elements assigned to their specific expertise, while the attorney leading the overall project will bear the responsibility of the overall work outcome and for deliverables that are handed out (e.g. the submission to court). The details can be adapted as needed for the setting at the respective law firm.

Secondly, especially in formalized proceedings such as litigation or administrative proceedings, deadlines are imposed by procedural rules, including the sanctions if they are not met. That gives deadlines a different importance than in software development and consulting businesses. While typical Agile settings have fixed timings, they also have flexible outcomes. In the legal setting, often the output (e.g. a court submission) and key content are externally dictated (e.g. the requirement to have delivered certain facts or evidence by a certain point in the proceedings). In such settings, you might need to deviate from typical Agile setup in the implementation. We will bring examples on how to do so in this workbook.

First things first. Clarity is essential. To achieve this, you need to define who is going to be accountable for what, and what the consequences are. You can use the template below to start clarifying Accountabilities, Roles, and competencies. This is also helpful outside an agile setup. It’s quite likely that there are global requirements, defined by the organisational environment, to consider anyway.

If you want to go even deeper, you could hold a team workshop to discuss what every team member needs to fulfil their job in the best possible way and what type of collaboration or support is needed.

After that, it is all about assessing and adapting! Try things out and meet regularly to figure out what works for you and what doesn’t. Then adapt. Over time, you will find better and better setups.

An important sidenote on ideal team size. Agile Teams typically consist of 5–8 people. This way, the two Accountabilities that take care of the WHAT (Product Owner) and the HOW (Scrum Master) could technically be held by different people, while still having team members with different skill sets to build a truly cross-functional team. The ideal Agile team should combine all the skill sets needed to deliver value end-to-end. While this might be considered “ideal”, it is still possible to use the same principles with fewer people. At some point one person will just have to take on several Accountabilities at once. You can even apply most of the principles as a solo attorney, to visualize for yourself or your client where the responsibilities lie, or include external people (e.g. virtual assistants, social media managers), who help with your work.

Story

Of ownership and responsibility

Now that they have decided who is part of the actual team and who is an external stakeholder, the team members start discussing their Accountabilities. Starting with defining who decides what work will be addressed and when it is finished, they figure their team is too small to have one person be responsible for only one task or Accountability. They will need to manage the respective Accountabilities part-time as otherwise they would not have sufficient people to do all the work.

They start by designating Alice, as partner and the attorney responsible, to be their Product Owner. She is responsible for the work outcome both from a professional rules’ perspective (as she will sign court documents and is a partner of the firm) and internally as the “supervisor” of the team. They briefly touch on the question of what the team members need to know to be able to determine when work product is finished without first consulting Alice but leave it for now as a task too challenging for this stage.

The next Role they intend to fill is the Scrum Master. After a brief discussion, they decide that Gabriel should take this Role as he likes to observe how the team is working and currently also has the lowest involvement in decision making as the junior associate. He confirms that he plans to dive a little more into the methodology, as he is actually very interested in learning more about Agile work.

While Fiona has no formal Role, due to her sufficient experience as associate, she is best equipped to take ownership of work and prepare it up to the point that Alice can then determine whether it is ready for delivery.

Similarly, the team’s assistant Oliver does not receive any formal Role at this time, keeping his function as taking ownership of certain work activities.

Example

This is filled out for each team member:

Template

Fill out the table above for yourself and ask everyone in the team to do the same. Agreeing on the general tasks and responsibilities will help with Accountability later. These tables can be reused if team members have specialities (e.g. legal fields, evidence gathering).

Goal:

What is the goal that this Role aims at?

Why does this Role exist in my specific context?

Responsible for (Relevant tasks):

What are the thing I need to get done?

What am I doing day to day?

What can others see me doing regularly?

Competencies needed:

What are the core skills needed?

What knowledge is needed?

Support needed:

How can the Team support me in this Role?

What are the things that I need help with?

Where do I need consulting from others?

What is NOT my job?

What is this Role NOT responsible for?

What are the things that I am not supposed to do?

Tools needed:

What do I need to fulfil this?

Budget?

Software tools?

When talking about the people involved in a legal project, those outside the project team should also be considered. Stakeholders are all people or even institutions (e.g. legislature) who have an interest or may affect the project. They consist, for example, of all team members in the law firm and on the client side who are part of the project, suppliers, and the counterparty, if any.

The core message of this chapter is that it is important to deal with stakeholders and assess them, and we want to show how to visualize this process. In practice, you will not map your stakeholders for every tiny case, but the more complex, the more critical and the bigger a case gets, the more important it gets to keep track of all the stakeholders involved and to know how to deal with them.

Even though it is the Product Owner who mainly deals with the stakeholders, it helps to visualize them so that they are transparent for everyone involved. Stakeholders can be shown on a grid which shows their infl uence on one axis and their interest in the project on another. For a more detailed assessment, a table can be fi lled out that deals with each individual stakeholder. On each one, it is noted how big their infl uence on and interest in the project are. From low “-“, through neutral “0”, to positive “+”. The last column consists of a note how to deal with a stakeholder of a particular rating or comments on an individual person.

Story

Of witnesses and other stakeholders

The team’s client, Bob, reacted well to their Agile project and our team is thinking about being even more open. First, they have a meeting with the client’s project manager, Caleb, to introduce more details about the project and the people involved. They already know about the counterparty, Eric, and his company but they neither know much about Horizontal Building’s customer, nor about potential interfaces with other third parties. While they have ample experience in explaining to clients about the challenges of working with witnesses, Gabriel read about stakeholder management when he delved into Agile literature. They decide to implement the stakeholder tools often used in Agile to get a joint understanding with Caleb and Bob about who is directly or indirectly involved in the case and how much infl uence each stakeholder has. The stakeholder map might have an impact on the fl ow of information, based on the actions regarding the different stakeholders. With this you should not forget to inform any important stakeholders.

Example

The team sets up a stakeholder map for the current case:

Template

Agile is an iterative approach. Within a predefined frequency, the team sets goals, revisits tasks, and organizes its work. These activities provide the team with an overview of what the whole team is doing and the requirements, thus creating a higher level of transparency and, ideally, understanding. Most often, this transparency is achieved with Kanban boards (Chapter 5), which represent the workflow and tasks of a project, a person, or a whole team. It is important to note that all this is aimed at helping everybody involved to make sure the right things are being prioritised and achieving a more balanced workload in the team. The transparency should not be abused to micromanage. The team as a whole is responsible for making sure the work gets organised properly.

One Agile iteration is commonly called a Sprint. It has a defined length, which can be as short as one or two weeks or as long as four weeks, and follows a clear recurring structure of Agile meetings (Chapter 6 Meetings). In practice, it might be helpful to use your existing meeting structure. That means organising a Sprint between recurring meetings like jour fixes could be an easy way to get started. Think about the rhythm of work you usually have. What are key meetings, alignments, and milestones? Write down regular meetings as well as typical triggers of activities that have a significant impact on your work schedule. Do the latter incur typical patterns? For example, if you have a weekly jour-fixe, a Sprint duration of a week can work very well.

The goals are set in a way that usable output is available at the end of the iteration, while it is perfectly fi ne to split the expected output into small deliverables, provided these are usable and useful. This output is usually presented to the client to align on whether their requirements are met and then, if needed, the requirements for the next Sprint are adapted.

Story

Learning from the case

As a senior associate, Fiona has sufficient experience to work independently on certain clients, yet she’s near enough to her legal studies that she still remembers how she first got in touch with different specializations. What drew her to litigation specifically was that she was able to really push the limits for a client, work internationally, and be sure to have plenty of unexpected turns regarding evidence and other aspects of each case. Neither she nor her colleagues are new to changing circumstances. At the same time, she is very keen to have better tools and a framework that makes it easier for her legal creativity to flourish.

What Fiona read about Agile work sounded promising in that regard, as it expressly addresses working with uncertainty in projects and learning in iterations. One question is really puzzling her: because Agile is supposed to work in time-boxed iterations, how do these Sprints match the requirements of deadlines set by courts and clients?

Since the Agile methodology originates in software development, she thinks about asking her IT colleague Igor whether he knows more about the theory. He does not, but after asking around it turns out that Gabriel has a friend who works in IT consulting, with whom he is meeting the following evening. Fiona asks him to take her questions with him, in case his friend knows the answers. Gabriel’s friend Sara does indeed have considerable experience in the field. She studied management and holds a bachelor’s degree in IT. Now she works for one of the top-tier IT consultancy firms. They are often called in to stalled projects to fix the project management. She specifically focuses on the methodologies being used, including Agile. Bringing up Fiona’s question, Gabriel learns that it is a common misconception that deliverables are only shared at the end of a Sprint. Rather, it is up to the Product Owner to decide on when a work product is finished and delivered to the client.

The next day, Gabriel shares what he has learnt with Fiona. On that basis, they think that in the short run it is a perfectly good approach to plan with the usual deadlines, adapt if needed, and to have delivery or submission deadlines that are not at the end of the Sprint. They would first start with their current planning rhythm, which is aligned to their weekly team meetings. They can still learn and adapt on their Agile journey. Based on Gabriel’s experience discussing with Sara, Alice invites her team to think about who could consult them on a small volume basis.

Example

Internal meetings:

External meetings:

Template

Internal meetings:

External meetings:

When dealing with attorneys, clients sometimes have the impression that they are a black box, where a question or request goes in, then some magic happens and legal advice or a legal document comes out on the other side. Which means they often don’t know what the attorney is doing, what work goes into a task, or if they have even misunderstood something or are lacking crucial information. There are seldom early feedback loops with clients out of fear something unfinished could put off the client and, even worse, cause a liability.

With the methods and tools provided in this book, transparency and communication can be improved with the client. The better the work is defined, the better the relationship becomes because there are fewer discussions about scope and ultimately price; risk as well as liability are reduced.

It is not just the relationship to the clients where these methods improve transparency—also between the attorney responsible and their team. When the expectations and requirements are clearly stated and communicated, it not only reduces risk but also helps employees to learn. All of this requires that some overall criteria are defined (see also Chapters 4.8 Definition of Done and 4.7 Definition of Ready), but this only helps with improving the workflows as well as the quality.

Mapping out the communication flow is always a good idea when you implement operational standards in your law firm. The templates below can also be filled out as a standard and then be adapted for specific clients if needed. Communication can be done by e-mail without elaborate collaboration tools, but mapping the flows can also serve as a first step to help implement new tools. However, that is a project for another day (or book). For Agile working, these flows will help, for example, define the status of a card in a Kanban board, which we’ll talk about later in the book, and further transparency and communication in a project.

Story

Total transparency?

Transparency can have two directions: internal and external. As our team has decided to keep the team to their internal core team, a significant part of the communication will be external.

For their internal communication they decide to aim for transparency towards each other, while keeping the changes rather limited for the moment, as they do not want to overburden themselves. Encouraged by the discussion about who the team consists of, Alice decides to stress that she wants feedback and suggestions and they all agree that they will openly provide it. They concur that being open is a sign of strength.

They now must decide if they want to disclose to their new client that they are trying out Agile methods. This is a tough decision, as they do not want to seem to be experimenting on the client’s case. They weigh different options, from keeping it all to themselves, to openly bringing it on the table. Some intense discussions later, they resolve that they will go with radical transparency. They will clarify that their work won’t suffer and that they will revisit the methods regularly. If Bob reacts positively, they intend to go further and make parts of their cooperation Agile and align with Bob regularly to match the case’s relatively high number of options. Their “sales pitch” is that they want to be able to accommodate both what seems possible and changing business needs as quickly as possible. On the other side, they do not plan to explain in detail how they intend to work, giving examples that show a flexible approach that avoids sticking to paths that are not ideal anymore.

Example

What is the communication flow from the client to the law firm and vice versa?

• Bob e-mails, calls or messages Alice and Fiona directly. If the client contacts only one of them, they forward the information (e-mail to the further team members).

• Both Alice and Fiona communicate with the client directly whilst copying in the other one and Gabriel.

• Gabriel may prepare e-mails that are then sent out after Fiona’s or Alice’s approval. What is the communication flow within the firm?

• Alice, Fiona, and Gabriel are on all project-related internal communication.

• All three have access to the communication that came in from the client or external parties. What is the communication flow with other external parties?

• Only Alice communicates with the counterparty and their attorney directly.

• Fiona may communicate with other third parties, e.g. expert witnesses.

• Gabriel only communicates directly with external parties when specifically instructed.

Where are documents stored internally in the firm?

• All documents and communication are stored in the firm’s document management system and are accessible to all the team members.

How are documents shared with the client?

• Documents are shared with the client through the law fi rm’s client platform; at Lawyering & Co, e-mails are avoided as much as possible, so that all tasks and documents are centralised and accessible for everyone who needs them.

Template

Whilst the tools later in this book help define in detail how communication and transparency can be executed, it helps to clarify some points with the team (if there are not already law firm standards).

• What is the communication flow from the client to the law firm and vice versa?

• What is the communication flow within the firm?

• What is the communication flow with other external parties?

• Where are documents stored internally in the firm?

• How are documents shared with the client?

Agile provides a formalized framework that enables you to do work that requires both technical expertise and creative skills. Whilst this is a process, think less of Business Process Management than of a structured approach that helps people do what they do best. The Agile manifesto states “individuals and interactions over processes and tools”—this does not imply there is no process, but it clarifies that the collaboration between the people is more important than sticking to a strict sequence of events.

Processes

Law firms and legal departments often have numerous complex and time-consuming processes that can be streamlined and optimized to improve efficiency and reduce costs.

In addition to streamlining existing processes, Law Firm Operations also works to develop new processes overall. Processes are a critical component of Law Firm Operations, and success in this field requires strong process management skills, as well as an ability to analyze and optimize complex workflows.

Technology

In addition to implementing new technologies, Legal Operations professionals are also responsible for managing and maintaining existing technology systems. This includes overseeing the implementation of upgrades and updates, troubleshooting technical issues, and managing relationships with technology vendors.

Technology is an important field of Law Firm Operations and success in this field requires a strong understanding of legal-specific technologies, as well as an ability to identify new technologies that can help to drive improvements in Law Firm Operations.

People

While technology and process improvements are important, it is the people who use the technology and drive the processes that ultimately determine the success of Law Firm Operations initiatives.

Overall, people are a critical component of Law Firm Operations, and success in this field requires strong collaboration, communication, and relationship-building skills.

In Agile, work is broken down into Elements which get ever more detailed. During the overall process, the team starts with a high level of Elements, without much detail, and as more and more information is collected the work is described in more detailed Elements. In this chapter, we will describe a typical set of such Elements describing work: the Goal, Epics, Items and Tasks.

The granularity also reflects what can be done within a certain timeframe. With the Goal being for the whole project, Epics usually need more than one Sprint, Items can typically be finished within a Sprint and a Task should not take longer than a day. While each project should have a clear Goal, the level on which the actual work sits depends on the expected duration of the work involved in executing the Element. Whilst an Element might start as an Epic during its lifetime, it will become increasingly specified. We will explain the Elements of the specification throughout this chapter.

To bring this to a more general level, there will be Elements that are rough ideas that cannot be executed (yet), and you may not yet have the time to deal with the details of them (e.g. re-branding strategy), but you still note them for future use. This helps to plan for a longer term and keep track of ideas.

When a new task comes in, you always ask yourself the question: Do I have all the information I need to execute the work? This is closely linked to the specific properties of the Elements we go into detail below.

Note that different naming conventions exist, both depending on frameworks and tooling used. The principles remain the same, irrespective of that.

The Goal defines the overall theme or purpose of the project or product—the overall outcome your client wants to reach, or you want to reach in your law firm. This could be successfully managing a trial, closing an M&A deal, getting a new contract signed, but also internal projects like implementing a Legal Tech solution in the law firm. It is the first step of the attorney and the client or the attorney and their internal team to get to the individual Items where it is finally defined what needs to be done. If the Goal isn’t clear, the project should not move on. For example, if the Goal differs in the question if the opposing party should be sued over a faulty product, or a contract shall be written for a service provider to fix this product, the stakeholders need to clarify it. That doesn’t mean a Goal or strategy can’t change over the course of a project, but it is vital to always be able to communicate the current Goal so that work can be aligned. The Goal is then broken down to smaller parts: Epics, Items and Tasks, which describe the work that needs to be done to achieve the Goal.

At this point, the detailed to dos and how the work will be done are not defined yet, e.g. if you can settle before a trial, if it has to go to court, or even further to an appeal.

Story

Do we know what we do? And why we do it?

Now comes a phase in which our little team might encounter a few surprises. The expectation certainly is that they know what they’re doing. They do, don’t they? Certainly, in many regards. Their legal and procedural expertise goes without doubt. They manage big litigation effectively. Their Agile methods will neither change nor question that, but there’s something that challenges them more than they’ve expected. And that’s not only doing their work well, but also concisely describing it in advance.

As each project works best with a shared Goal, they convene to recap it in a sentence. That is where our younger colleague Gabriel learns a valuable lesson. He would have set the Goal as: “win the case for the client”, but his more seasoned colleagues warn him that he should not commit to that, as life (and law) brings too many surprises, and they might be liable if they don’t win the case after all, and the Goal was communicated to the client. It is good to strive for that, but the actual committed Goal will account for uncertainties.

Example

After some discussion, our team defines their Goal as follows:

Goal: Achieving a commercially sound and legal outcome based on the circumstances and client’s choices.

Template

The Goal is: ...

When the (work) Elements that lead to the Goal are first written down, they often have the form of an Epic. There, the first general description is added, but it is too large to be immediately executable by the team. The further you get into a project, the better the individual Items of an Epic emerge. The Product Owner takes Epics, turns them into Items and defines them—if necessary, in coordination with the team—until they are ready to be added to a Sprint.

Specialised attorneys might find themselves with recurring Epics. These may be standard procedures in special types of cases, similar types of contract projects, etc. Not all Epics of a project and their content are known at the start of a project; some can be standardised and made into templates for future use. An Epic is done when all the Items it contains are done.

Story

Planning a litigation project

Given their law firm has the ambition to win its clients’ lawsuits, defining the Goal initially felt like a small detour to the attorneys, but eventually they found that it helped the sharing of experience amongst themselves, and granted clarity on how to explain to their client what is achievable in the setting they have.

With that in mind, they now settle down to plan the project. Litigation often spans a longer period, which fits well with the highest actual work Elements, the Epics. The team reiterates that trials usually take more than a Sprint and they mull over how they could translate and break up their general experience into Elements that also serve as an explanation to their client. They want to have the client on board throughout the process, want him to understand both their approach and the litigation, but as litigation often comes with time pressure, being able to get started quickly is important. This is why Alice as the partner is hesitant to implement a new method of working and add more work for the team by defining parts of the process that they hadn’t done previously. Because she is committed to trying Agile methods and the timeline in this setting is only of medium urgency, she was ultimately comfortable with it.

Whilst their description of their work in Elements is first and foremost intended for themselves, they can show these to the client to explain the process. Now they break down the legal proceedings into Epics. They are fully aware that certain properties of the litigation may change, for example, in the case of promising settlement discussions; when needed they will adapt the Elements to reflect this.

Example

In our story and the respective litigation case, the team’s initial epics look like this:

• Establish the facts of the case; gather evidence.

• Assess legal basis of the claim.

• Contact the opposing party claiming the amount.

Further Epics would be drafted depending on the evolution of the lawsuit, e.g.:

• Set up settlement meeting.

If the settlement fails:

• Draft statement of claim.

• Review the counterplea and decide on next steps.

Template

The Epics are: ...

Items are the next level of detail and specificity after Epics. Usually, Epics consist of multiple Items, which are ready to be added to a Sprint, but do not necessarily contain all the individual to dos.

When defining an Item, methods that can be used are, for example, the DEEP or INVEST criteria:

DEEP Criteria

Detailed: it needs to be clear what must be done in a certain Item.

Emergent: the Backlog is dynamic in nature and evolves over time. As more and more knowledge is obtained new Items can be added, others can be removed.

Estimable: the effort it takes to execute an Item or its value needs to be sufficiently estimable. To which extent depends on your business model, e.g. whether you need it for capacity planning or pricing. If it cannot be estimated (yet), the Item is not ready to be added to a Sprint, the contents might have to be defined further or it should be split into multiple Items. Estimation is an art in itself; we therefore suggest that you first stay with the approach to estimation that you are currently use, that should do for your first Agile setup. There are various methods for estimating complexity within the Agile toolkit. For the purposes of this workbook however these go into too much detail, so it won’t be covered here. Estimations by some sophisticated method can be useful but are by no means necessary.

Prioritised: importance (value), urgency, risk, and other criteria can be factors to prioritise an Item over others.

INVEST Criteria:

Independent: it can be implemented as a separate and self-contained Item.

Negotiable: like a contract, it needs to be clear what the specifications are. With clients, the contents of an Item can be negotiated. In essence an Item should be a conversation piece.

Valuable: being aware of the value an Item brings to the customer/client and being able to show it helps you already in the communication with a client and the underlying pricing.

Estimable: as above, the Item needs to be well enough defined to estimate it.

Small (or sized appropriately): this is related to estimable, because the smaller an Item, the easier it is to estimate and the lower the risk of the Item itself and of misestimation it. Also, it should be possible to implement an Item within one Sprint.

Testable: the Item is tested by checking it against the Definition of Done and Acceptance Criteria. The definition of an Item, with the help of these criteria, must be detailed enough that it can be worked on; and can contain the Elements you find in the following chapters (in Chapter 4.9, Bringing it together, you see a full Item in detail). Once this is reached, the Item can be added into a Sprint during Planning (Chapter 6.2). This is important to team members, so they know what is expected of them but even more so when dealing with a client. The better the Items are defined, the easier it is to price them precisely for a client, to manage the client’s expectation, but also to deal with a potential liability if certain aspects are explicitly not part of the Item. As with Epics, it is possible to draft standard Items that already have, for example, a list of Tasks included. This could be a standard checklist for trial preparation or contracts. This ensures that nothing is forgotten and also serves as quality control.

Story

Alice, Fiona and Gabriel look at their work and now see a Goal and Epics written down. The list is shorter than they would have initially expected, but it nevertheless feels like a first significant achievement, even though they know they still have a long way to go in their Agile journey. This comes with mixed feelings. They briefl y consider cancelling the experiment but eventu- ally decide to keep going. They’re still energized and looking forward to pushing the limits, especially Gabriel, who is the newest team member and youngest attorney, arguing in favour and offering to go the required extra mile himself, if necessary. He offers to create the fi rst set of Items to have a better basis for their discussion and to speed up the process.

Given that the next deadline of this specific case is still some days away, Gabriel decides to first finish his work on a different court submission he’s working on. He makes a mental note that he will try to find out how teams deal with multiple projects at the same time; maybe he can ask his expert friend Sara about that?

In the elevator up to their office with Fiona, he jumps right into discussing their case. He recalls their Epic “Establish the facts of the case” which is waiting to be broken down into smaller pieces that can be done within a single Sprint. They come up with a solution that is clear enough for them to think that Alice will be fine with it.

During their exchange, they briefly think about whether this has been the best process. From what they have read, they thought the team should define the work Elements as a team effort. However, given that they have had a hard time finding time together and are all struggling with other tasks, they agree to continue for now. Maybe there are some Agile methods for meetings as well, which Gabriel makes a mental note to check out later.

They had already defined some Items and started working on them, like meeting the client to get the big picture of the case. One of the other Items they discuss for quite a while is: collect the proof. Unnoticed by Gabriel, Fiona starts to frown slightly while he is explaining his reasoning. She just listens, though. After Gabriel finished presenting all the Items he has thought of, Fiona suggests addressing this one. She thinks that it might well not work out as Gabriel has thought of it. Experience does help sometimes. She asks Gabriel a few “whys” and in the end explains her concerns. They discuss and both agree that the Item should rather be: “Set up a table to align the arguments”. They’re positively surprised about how smoothly they’re sharing knowledge, thinking and experience as they go through the process.

Example

Epic: Establish the facts

Item 1. Meet the client to get the big picture of the case.

Item 2. Draw an overview of all parties involved in the case, including their position and relevance.

Item 3. Identify the people able to provide detailed information on relevant issues and interview them.

Item 4. Discuss with the client the expected position of the counterparty. Item 5: Set up a table to align the arguments before court with the submission/argument, relevant proof, the legal basis, and potential applications to the court.

Template

Epic:

Item 1. ...

Item 2. ...

Item 3. ...

Item 4. ...

Each Item should also contain information about how that work is completed. This is achieved in the form of Acceptance Criteria. Defining these helps everyone involved understand the quality criteria of an Item. If the Acceptance Criteria are not met, an Item cannot be finished. In law firms, there are multiple aspects that need to be considered: the client’s expectation, the (formal) standards of the attorney, and the legal framework affecting the Item. The Acceptance Criteria of an Item between client and attorney might look different from one the attorney assigns to an employee where there might be additional steps involved the client isn’t aware of. Overall, Acceptance Criteria improve clarity and communication within the attorney’s team as well as between the attorney and their client.

While the team itself should be able to determine whether the Acceptance Criteria are met, there is a speciality to the legal industry: due to regulatory requirements we suggest that the attorney responsible makes the final decision on whether the Acceptance Criteria are met and, thus, whether the task is finished.

For practical and liability reasons, criteria like “winning a lawsuit” or a “watertight contract” should not be added to Acceptance Criteria. Acceptance Criteria need to be easily checked and clearly determined whether they are met or not. For Items in a law firm, the Acceptance Criteria might look as follows:

Acceptance Criteria for a contract project could be:

• General legal clauses are drafted.

• Contracting parties, contacts and signatories are entered.

• Obligations of the parties are defined.

• Commercial framework is defined.

• Client’s business model is implemented.

• Required approvals/licenses have been obtained.

• Contract is balanced and fair to decrease the complaints from the client’s contracting parties.

This can also be broken up into to Acceptance Criteria for initial contract drafting and contract negotiation.

Acceptance Criteria for a statement of claim for a lawsuit:

• Facts of the case are recorded.

• Evidence has been collected and assessed.

• Statute of limitations has been checked.

• Basis of assessment is calculated.

• Opposing party (parties) has been entered.

• Appropriate court has been assessed and entered.

• Facts of the case are drafted and supported with evidence.

• Legal assessment has been drafted.

• Client’s requirements were added.

• Damages have been calculated.

• Claim has been drafted.

• Cost statement has been added.

Story

Knowing when you’re done, first part.

During a brief joint coffee chat in the late afternoon, Gabriel describes to Fiona his feeling of finding nuggets of information yet having many more questions. She supports him, saying that she would very much feel the same and that it might be good to discuss it with somebody more experienced. This reminds Gabriel of his good friend Sara, the IT consultant, who had offered to help when they last met. After coffee, he calls to invite her to a joint lunch as he’s sure Sara and Fiona will also get along well, with the added benefit that they could discuss a few questions. Attorneys have inquisitive minds and a tendency to find challenges and tough questions.

It might be a gift to anticipate problems, but here in this setting our two colleagues feel that they would enjoy being able to “just do it”. They already have the first question for Sara: who defines when something is good enough to be declared as done? Yes, they have heard about Acceptance Criteria, which state what requirements need to be met. They will try to describe these for a few Items, but they do not have a clear feeling about who would have which responsibility yet. In any case, they want to add the Acceptance Criteria to their Items, so it is clear what determines whether the Item has been finished. That would also be beneficial for Gabriel who does not yet have that much litigation experience.

Example

Acceptance Criteria for Item 5:

Set up a table to align the arguments before court with the submission/argument, relevant proof, the legal basis, and potential applications to the court.

• The table consists of the following columns: argument/submission, proof, legal basis, application, other info.

• A list of all arguments/submissions to the court is written in the first column.

• All columns apart from “application” and “other info” are filled out.

• All proof is linked to the relevant file in the file system.

• The table is easily readable when in court.

Template

Element: ...

Acceptance Criteria:

• ...

• ...

• ...

• ...

The Definition of Ready (DoR) contains criteria that apply to all Items. DoR are the requirements that an Item needs to adhere to in order to be ready before it can be added to a Sprint, and therefore executed.

Definition of Ready can be:

• Dependencies are clear, the team can start working on the Item immediately.

• The team understands what the value the Item delivers is.

• Acceptance Criteria are clearly defined.

• The Item can be finished within one Sprint.

Remember: if the Item would take longer than a Sprint, it should be split or be moved to an Epic level.

Story

Better not lose time

When Fiona was a junior associate, she worked for a different law firm but quickly decided that was not where she wanted to stay. There was an expected physical attendance in the offi ce, which meant her evenings were gone even when no work needed her attention. On the other hand, there was much idle time in-between because the partner kept all the information to himself. That was when she met Alice, who seemed much more relaxed. Whilst the environ- ment in this fi rm is much better, due to Alice’s many court hearings and client lunches, the problem of idle time waiting for instructions still exists, albeit to a lesser degree. For Fiona the problem had nearly gone as she has clients of her own, but as she started to go to court regularly herself, the same problem emerged for Gabriel. She wanted to address it and Alice once said the same to her. When this whole Agile thing came up, Fiona hoped that it might be the solution to their problem. And while it is very rare that a methodology on its own can solve all problems, she hopes that Agile is a puzzle piece to address this issue.

As she is heading to Oliver’s office to ask for help in a few organisational matters, she runs into Alice who just returned from a notary appointment for a different case. Her appointments for the day done, Alice is curious to hear how her team did with the new methods. Alice and Fiona start discussing how the work could be organized to make it easier for their younger colleague to become more active himself. Because Alice is constantly optimizing her time, she started listening to an audio book about Agile on the way to her appointments and the latest chapter was about the Definition of Ready. The two ponder what Gabriel, and potentially Oliver, would need to be able to start work on a specific Item without further input from them. This comprises merely being transparent about what needs to be done. If they do not share the information, Gabriel cannot start the work or will end up needing information all the time to continue, which will interrupt him and whomever he has to ask. They set up a checklist of what needs to be prepared or known beforehand for the specific Item so that the respective team member can start their work. This checklist is their Definition of Ready. They agree that they will add this to each Item before work on it can start, as Agile methodology defines.

Example

Template

A User Story is a method to structure an Epic or Item and define it, that puts the focus on the recipient—the user, or person that should gain value out of the work done. It can be the attorney who receives input from his team on internal matters, but most often it is the client. The User Story can be defined together with the client (or customer in internal projects) and is supposed to help you to put yourself in their shoes and can be the thread that leads you through the project. A User Story describes the perspective/role of the relevant person, what that person wants to achieve and why. If you write User Stories from the point of view of your client, that will help you also gather a better understanding of their needs. This is not to be confused with the point of view your client takes in a legal dispute, but more what they want to achieve.

A user story builds on a simple sentence: As a, I want <outcome/goal>, so that.

When you define a User Story as the guideline for your Epic or Item, it helps you keep the user’s need in mind when defining the details of the Element.

As an additional exercise you can add questions like: How would the Goal change if the person would have a different Role? Who else might have similar Goals? Are there other ways to reach the benefit?

It is important to note that the term “User Story” is often used to describe two things at once. On the one hand, it means the way (method) of describing requirements (As I want <outcome/goal>, so that ) as well as the Item itself, that contains the User Story. So, when someone talks about a User Story that needs to be done, it usually means the actual Item, that needs to get done, that might be described using the method “User Story”.

Story

Taking the client perspective

While his colleagues are deep in their legal work, our interdisciplinary mind and youngest law firm team member Gabriel dives deeper into the Agile methods; and he likes it. On his journey he learns many things they were unaware of, but with the positive feeling that they can learn along the way. Even with missing puzzle pieces, the process would be useful.

The first tool he spends time on during this phase is the “User Story”. As good observers, the attorneys in the team have already had a feeling that it’s not easy to concisely describe what’s needed and to put themselves in their client’s shoes. To his delight, Gabriel identifies the User Story as part of the answer to this challenge. To practice his skill, Gabriel takes a few Epics they have worked on and starts to describe the key outcome, client and why they profit from the outcome. He is honest in noting that it feels strange to describe the outcome in the “I” perspective of the client. Yet, in doing so, he experiences that just being focused on the person for which the desired outcome is described already starts to shift his view on the distinct topics to a more client-driven perspective. Next, he first takes a few of the Items they have worked on and describes them again in the form of a User Story.

Example

User Story for Item 5:

Set up a table to align the arguments before court with the submission/argument, relevant proof, the legal basis, and potential applications to the court. As an attorney, I want to have all arguments and relevant details easy at hand, so that when I go to court and discuss a particular argument, I don’t have to look for the most important information.

Template

User Story

As a __________________________________________________ <role/who is this person>,

I want _________________________________________________________ <outcome/goal>,

So that ______________________________________________________________ < benefit>.

The Definition of Done (DoD) groups overarching criteria that apply to each Item of a specific kind that need to be fulfilled to be considered done. If needed, a DoD can be updated over time to reflect additional findings. In a law firm, a DoD might contain law firm standards, but there might also be client-specific requirements that need to be considered for individual projects. Whilst in Agile methodology there is only one DoD, due to the varied nature of work in a law firm, there might be several DoD to reflect general law firm standards.

Our suggested approach is to start with a very general Definition of Done and create more specific ones based on recurring patterns that you see in Acceptance Criteria. If you keep seeing the same Acceptance Criteria time and time again, think about which field they would apply to and which parts could be standardised in a way that it applies to all Items in that field. This way you can create a specific DoD for a field.

Examples of DoDs could be:

Client Project DoD

• Acceptance Criteria are met.

• Legal assessment has been executed.

• Correct party/parties have been added.

• Formatting has been applied.

• The attorney responsible has reviewed and approved.

• Client has reviewed and approved.

• Submission of legal document according to the checklist for the kind of document.

• Proof of submission has been recorded.

Internal Law Firm Project DoD

• Acceptance Criteria are met.

• The project is legally compliant.

• Formatting has been applied.

• Internal stakeholder approval has been received.

• Attorney has reviewed and approved.

Story

Knowing when you’re done, second part.

While defining their Acceptance Criteria, Fiona and Gabriel discuss what needs to be included. For example, proper formatting. Is that part of the criteria or not? Having added the parties correctly? Verified the citations? Is that all part of the Acceptance Criteria themselves, would these topics better reside in a checklist that they might refer to, or is there an even better approach? Gabriel certainly wants to have everything at hand, while Fiona notes that the obvious stuff should not be mentioned as to avoid unnecessary formalities. But she agrees that it might be difficult for a less seasoned colleague to know everything. You learn from experience, don’t you?

They initially revert to starting a checklist and just having the case specifics in their list. Once back in the office, Fiona recalls that Alice gave her an Agile workbook, she skips through the pages and notices the chapter “Definition of Done”. She briefly takes a step back. Haven’t Gabriel and her just discussed Acceptance Criteria and defined a checklist for the work on the respective Item? Is that a different word for the same thing? The book disagrees. While Acceptance Criteria define the specific requirements for that single Item, it explains that the Defi nition of Done is a generalized description, a checklist for the things that all Items need to fulfi l. Well, not all Items need to fulfi l the same exact one, but the Defi nition of Done is the standardized and overarching part corresponding to the Acceptance Criteria. She drops Ga- briel a line on their internal messaging system about her finding. It makes sense and can align to their internal work organization, the firm’s knowledge management and, last but certainly not least, also training and onboarding.

Example

Within a litigation project there might be Items with a few different Definitions of Done, depending on the required outcome, e.g. one for factual analysis and one for court submissions.

Template

In software that has Kanban boards included or was specifically made for that purpose, numerous properties can be added to a card. These can include projects, clients, tags, assignee, Sprint, and many other things that then allow you to filter a Kanban board and also provide reports on progress at different levels.

In Agile working, answering the question of HOW to work is largely up to the team. However, since we bring a lot of different perspectives together (talking about cross-functional teams), tension within the team is to be expected—and that is a good thing! As long as it stays productive. This is where another type of Accountability comes in. This Accountability is typically called the Scrum Master, taken from one of the most famous frameworks: Scrum. The Scrum Master helps the team by facilitating decision-making processes and supports the team in finding the right way for them to work and to use the frameworks that help them. The person that takes on this Accountability therefore serves as a methodical guide, sparring partner, facilitator, coach, or trainer—whatever is needed by the team or the organization in order to remove obstacles (shortage of resources, formalities that impede the team, etc.) and become as effective as possible.

So how does all this fit together? First things first. To ensure good alignment of all the Elements, it is vital to know what you are aiming at (Goal). From there the question is “what has to happen, so that we can achieve this?”. The Idea is to identify the big things that need to happen (Epics). Those don’t need to be super detailed yet. To get started, it is enough to have a rough idea of the main topics. The User Story method can be helpful here, as it forces one to think about an Epic starting from the desired outcome and then goes backwards. Once you have some Epics defined it’s time to split them into Items that can be done within one Sprint. Here you can use the User Story method once again. Starting with the User Story provides a great baseline from which you can then add more and more details to your Item/Epic until it is clear what it contains.

To make sure we cover everything needed for the team to start working when defining Items, it can be useful to define when an Element is sufficiently described and therefore ready to be worked on—the Definition of Ready.

From here the only question that remains is: “when are we done?”. This is where the Definition of Done comes in. A collection of overarching quality criteria that define when an Element is considered to be done. This reflects the standards of the team.

Story

Having things ready

Our two senior members of the team, Alice and Fiona, think that it might be interesting to have a quick chat with the team. They come to see Gabriel, who is happy for the distraction. Based on what he read about Agile teams in the morning on the way to the office, he suggests moving the discussion into the secretarial office and include their secretary Oliver, who has not been involved in their discussions about new processes yet. When introducing the topic to him, they quickly find that they’ll need to visualise all work Elements, so they decide to put them on Post it notes on the whiteboard and group them as well as possible. For the moment they pin them to the board in Oliver’s office, as that’s the place they all visit often. But they feel uncomfortable with the sheer volume of Elements, especially about how to bring User Stories, the Definition of Ready, Definition of Done and Acceptance Criteria together—which goes with which?

Help comes from outside this time, as Sara confi rms a lunch appointment for next day. While this will be without Alice for the moment, Fiona and Gabriel will share their findings with her in the afternoon. Sara turns out to be very pragmatic regarding their points: she suggests starting with Items having a User Story, depending on what can be described easily, and that each Item should relate to a Definition of Ready and a Definition of Done and feature clearly spelled out Acceptance Criteria. Like this, the team is always ready to work and the person working on an Item would always be able to tell whether it’s finished or not.

Just before they part ways, Gabriel remembers that he wanted to ask Sara about teams that only spend a part of their time in an Agile team. Her answer to the question was somewhat disillusioning. One would preferably have their team members work Agile full-time but she acknowledged that this might not be feasible. It is still possible, just a little more difficult to start working in an Agile manner if you also have to work non-Agile at the same time. This can still work, if there is a core team that has most of its time dedicated to it.

Example

Item 5: Set up a table to align the arguments before court with the submission/argument, relevant proof, the legal basis, and potential applications to the court.

User Story:

As an attorney, I want to have all arguments and relevant details easy at hand, so that when I go to court and discuss a particular argument, I don’t have to look for the most important information.

Tasks:

• Create the table.

• Fill out the table.

• Link the fields to the relevant files in the system, where appropriate.

• Format the table based on firm standards.

Acceptance Criteria:

• The table consists of the following columns: argument/submission, proof, legal basis, application, other info.

• A list of all arguments/submissions to the court is written in the first column.

• All columns apart from “application” and “other info” are filled out.

• All proof is linked to the relevant fi le in the file system.

• The table is easily readable when in court.

Definition of Ready:

• Acceptance criteria are defined.

• Item has been explained to the team.

• Dependencies are clear.

• This Item can be executed in one Sprint.

Definition of Done:

• Acceptance Criteria for the Item are met.

• Legal assessment has been executed.

• Formatting has been applied.

• File names have been issued appropriately and it has been saved in the correct place.

• All links to documents in the file system are working and updated.

• Correct party/parties have been added.

• Attorney has reviewed and approved.

Now for one of the most popular and most versatile tools used in Agile working: Kanban. Kanban can be immensely useful to visualize work and create transparency. It essentially stands on its own and can even be used out of an Agile context. No matter whether you are using classic project management (e.g. waterfall), Agile or any other form of organising, in many cases Kanban can be beneficial.

The basic idea behind it is to simply visualize the path that every single Element goes through, from start to finish. For that to work, Kanban uses board with cards to visualise their status. The change of the cards’ position reflects the development in the process.

In an ideal scenario this means that you can identify bottlenecks in your process very quickly and can start to improve it to achieve better flow, leading to a more efficient process. As a result, it is one of the favourite tools of many Agile teams.

There are many use cases in which Kanban could be used. Who knows, maybe your marketing team is already using one to organise their workflow or to schedule creating and publishing content?

In this chapter we will guide you through the basics behind Kanban so you can start experimenting with it right away.

As an alternative to filtering based on properties, cards can be grouped in rows called “swim lanes” due to their visual appearance. These can reflect team members, projects, topics, or categories of Elements, for example. The advantage compared to filtering is that swim lanes allow for a visual overview. They are equally useful where you cannot use filters, like on a physical Kanban board, or want to break up the board by topic, you might want to use swim lanes: they can represent people, projects, or categories of Elements.

Story

Breaking down complexity

Fiona and Gabriel meet in the kitchen by chance, both having an acute need for caffeine. Their Agile efforts take some additional concentration on top of their work, but they’re both clear they would not want to miss it. But besides that, there’s something else they notice; they have never included Oliver in their discussions, except that they’ve initially used his office and then once given him a Task and card but without much explanation. Somehow that does not feel right, as he’s a valued member of the team. They briefly think about how they could address it and decide to be very frank: they have not thought about this earlier and rather bring him in later than not at all. They’ll suggest having a joint lunch during which they’ll explain their journey and findings so far and will include him in their further Agile endeavours.

But there’s something else their first experiments with the Kanban board have shown them. It quickly gets hard to keep an overview in the “To Do”, “In Progress” and “Wait” columns. They’ll need to figure out a better way—maybe one of the books will give a hint. But first, they want to apologize to Oliver for not having involved him.

As they enter his office, they find his desk empty and decide to come back later but to their surprise, leaving the room, they notice what they have overlooked on their way in: Oliver was standing quietly at the Kanban board, which was temporarily placed at a side in the open space in front of his office. They quickly approach him and note that it’s a perfect coincidence as they wanted to discuss their Agile process with him. After telling their story, Oliver accepts their apology and comments that he is interested to get started. Without much thought, Fiona mentions that she really wants to address the clutter on the board and will dive into the books. Pragmatic as he is, Oliver suggests just adding lines across the columns in which the cards are assigned to people. Not knowing about the swim lanes concept, he has nevertheless described it. Agile is, in fact, a quite pragmatic approach to breaking down complexity.

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.

The Kanban board is an essential tool to make the work transparent and is used frequently in Agile processes while being versatile enough to be used in non-Agile processes as well. It is organised in columns which reflect the status of the respective Element. Each Element is represented by a single card that resides in one of the columns. The cards may have a specific order within that column, depending on the requirements of the team (e.g. priority).

In its most basic version, a Kanban board has three columns: “To Do”, “In Progress” and “Done”. Each card would start in the “To Do” column and move to the right across the board. A Kanban board can equally be implemented in analogue form (a whiteboard or flip chart) or digitally in a software tool.

A Kanban board can contain all Elements, from Epics to Tasks, which can get massive, especially when dealing with multiple projects. When using a digital Kanban board, you can have one board (or view) for each type of Element, or filter by Sprint or team member it is assigned to, to make this easier to work with on a daily basis.

In practice, you will start adding more columns to reflect your actual processes more accurately, even if you have a board just for yourself. The board is supposed to show you what is happening and where there are flaws in your process that you can address. Most commonly there will also be a fourth column “Wait” to indicate that an Element is worked on, but the team currently waits for input from somewhere else (e.g. the client, court).

Presenting work and its status visually on the Kanban board can help to identify bottlenecks and process flaws. Issues often become visible when many cards start piling up in a column because they remain there for too long. For example, an indication of a process flaw could be that Elements keep accumulating in the “Wait” Column. Either you have chosen a bad time to work on these Elements or the process is designed in a way that creates bottlenecks that keep blocking your work. In such cases, looking at similarities of the Elements in “Wait” stage can give you hints on where to look for potential improvements. You could also add columns for signifi cant steps, for example, designated statuses that you see very often (e.g. waiting for counterparty, waiting for court). On the other side, if the “To Do” column becomes empty in the middle of the Sprint, it might point to a situation in which you should have prepared more Items earlier so they meet the Definition of Ready and can thus be picked up by the team to be worked on.

Story

The missing piece

As noted earlier, our team at Lawyering & Co. had already decided to visualise their work organisation, currently in the form of grouped Elements in their assistant’s office. Detailing all Elements upfront is one possible option for project management, but in our case, this is not yet possible, which was a core factor in choosing to use Agile methods. To start, our team intentionally describe the known and more generic Epics for the later stages, as they know the proceedings could evolve dynamically and need frequent adjustments. For the later stages, they would specify the details before the start of the respective phase of the process. They are instinctively taking an Agile approach here.

Their visualisation is somewhat static, though; the team is missing the status of their Elements and looking for a better tool. Luckily, Gabriel’s methodology-savvy friend Sara pointed them to one: Kanban, with its extensive use of visual boards. Sara notes that there are many elec- tronic tools to do so, but Alice rejects that option for the moment. She stresses her role as a partner for the fi rm and her responsibility as well as the regulatory requirements: she does not want to introduce electronic tools at this stage. They would first need approval by their firm’s IT team and regulatory clearance before doing so anyway, so it would take too long for their case. They will investigate these later but give Igor a heads up that they will bring up this matter as a small project. Besides avoiding regulatory and technical challenges, this allows them to first get a better understanding of their needs.

Our team will initially just use the whiteboard in the office. All three of them have a look at the material they have and, as to their understanding, they should primarily write down the Items they intend to work on. So that’s what they’ll start with. They feel that this was a missing piece and are happy to know how to address this.

It is possible to add multiple projects, phases, participants, or levels of cards (e.g. Epics and Items) on one Kanban board, which renders it quite complex. Digital tools often account for that complexity, allowing properties on cards and providing the ability to filter them.

Each individual Element is represented by a separate card placed on the Kanban board. The contents of such card can vary depending on the type of Element, but you can also use Kanban irrespective of these more formalised properties. When you put a single Task as a card on the board, the contents of a card can be quite simple. In a simple version, the contents of the cards could be:

• Title

• Due Date

• Description

• To-do lists

• Assignee

Practice Tip: Cards with Tasks

When you work with Items and Tasks, you can use a separate card for every Task within the Item or have a card for the Item including the Tasks as a checklist. In any case, you will want separate Tasks if the responsibility to execute them lies between different people. In practice, it will also depend on the software or tool you are using, if Tasks are separate cards on the board.

Story

Letting go

After a brief feeling of elation, having taken up the challenge, our team quickly gets back down to earth as they start writing down their Items on Post-it notes. They find that it’s quite difficult to get the all the required details written down. Alice has left this to Fiona and Gabriel. As Gabriel intensely scribbles away on the cards, Fiona gives an exhausted sigh and decides to get a coffee. On the way to the kitchen, she doubles back and decides to pick up the Agile guide she has recently bought. She takes it to the whiteboard and, instead of writing cards, she goes to read about Kanban and the management of Items again. That turns out to be a good move, as she finds a key tip in there. The cards only need to be fully detailed when the team decides to move them into their “To Do” column, that is the part of the board containing the cards on which the team wants to work on next. The solution is that they just think about the details of what they will address in the next week. They will place the other Elements as cards on the board, but as mere placeholders, letting go of the details. In the end, they decide to take a different colour and use that for Epics and just note the items they already know on the Epic cards that are not relevant yet. That settled, the team writes all cards for the Items they need.

Example

Our team puts a task from Item 1. Meet the client to get the big picture of the case on the Kanban board.

Template

When designing the board, the layout depends on the workflow and process you want to reflect. As a general rule, cards move from left to right where the simplest setup of columns is: To Do, In Progress, and Done.

Our proposed setup contains five columns on a Kanban board, and the lifecycle of a card on it is:

1. Backlog When a new Element is newly introduced, it starts on the very left column of the Kanban board, the Backlog. While the card sits on the Backlog, before it is introduced into the next column, all prerequisites of it being worked on in a Sprint need to be fulfilled.

2. To Do In the Sprint planning, based on the priority given by the Product Owner, the team decides which Items and thus cards, will be worked on in the Sprint. These cards are moved from the Backlog into the “To Do” column for the Sprint.

3. In Progress When team members pick a card to work on, they move the card to the “In Progress” column and, if not already the case, add their name to it. You might note that it’s usually the team member who “pulls” the card, as opposed to a top-down approach in which work is pushed to team members. This transparently shows all team members that the respective Item is being worked on and whom to approach if questions come up.

4. Wait Sometimes a team member cannot proceed with an Item because they are waiting for outside input, e.g. a response from a court or other public body, an approval or input from the client. In that case, they can place the respective card in the “Wait” column to show that they have all to be done on their side at this moment and are waiting for input to be able to continue.

5. Done Once all work on an Item has been done, the attorney responsible reviews whether they can confirm the Item meets the Definition of Done. If so, they move the card over to the “Done” column. Note that, if an Element is not needed anymore, or the strategy changes, it can also be deleted. Cards can also move backwards, not just forwards. First, this allows the use of columns such as “Wait”, which require cards to be able to move back and forth (e.g. from “Wait” back into “In Progress” when the outside input has arrived and work on the card resumes). Then, in a law firm setting this method can be used for example when law firm employees reassign a task to the attorney who needs to check it (e.g. from associate “In Progress” to attorney responsible “To Do”) before it goes to the client.

Practice Tip: when to add details to a Kanban card

A card on the Backlog may be quite short; it just needs to be understandable enough that the team knows what it is about. When, during a Sprint Planning, a card is chosen to be addressed in the specific Sprint, that means it will be moved to the “To Do” and the details of the specific Item will be added. The most important thing is that the card includes all information that the people need to get working.

Practice Tip: Kanban without Sprints

A Kanban board with cards that represent Items or Tasks can also be used without a Sprint setup. In this simplified case, the attorney adds tasks to the “Backlog” and discusses with the team which of them are the current “To Do” Items. In this case, it would also be possible for the team members to pull Items out of the “Backlog” when they are finished with all their cards that were in the “To Do” column.

Practice Tip: Solo Kanban

Due to the versatility of Kanban, it can also be used for one person to organise themselves. In cases where simple to-do lists have become too elaborate, hard to prioritise, or too many are blocked by other people, a Kanban board can also help a solo attorney organise their work.

Story

Formalized freedom

Having decided that the full granularity is not always needed, creates a feeling of relief. What briefly seemed like an unsurmountable task is now in clear reach, yet the next obstacle is right around the corner. They have the cards, but where do they fit? That’s the next question Fiona and Gabriel will need to resolve, with Alice giving them free reign once again. If they had been asked for their honest opinion, they would have probably admitted that they’d gladly accept a predefined set of cards for a litigation procedure as preparation. On top of the details every type of Element contains, they soon realize that these contents can be replicated for other projects. They figure they could, over time, create a set of standard Elements and cards for certain projects they deal with again and again. But first, they get their hands dirty and get going with the task at hand.

Whilst they did not do any formal Sprint planning (yet), they need to organise the cards. So, they prioritize what’s needed for the project first, have a look at dependencies, and do a rough estimate how long it would take. What can be achieved within the next week before their next team meeting? Those would be the cards they would make sure are ready and place in the “To Do” column. Everything else would be parked in the Backlog. Then they decide together which Item each of them would work on that day.

Getting started on the matter, Fiona takes the Item: “Draw an overview of all parties involved in the case, including their position and relevance” as her next one. Gabriel, having a smaller work load, takes the somewhat more work-intense Item: “Identify the people able to provide detailed information on relevant issues and interview them“.

This second Item includes an activity that their assistant Oliver would usually do: organise the actual meetings. Gabriel thinks of assigning this Item to himself, but they ask Oliver to take over this assignment. Since the first Task of the Item is identifying the right people and writing them down, which sits with Gabriel, Oliver’s task will depend on them being finished. Gabriel revisits his notes from the initial discussion with Bob and Caleb and recalls that they suggested having an electrician in the client’s team. He thinks that there might be additional people at Horizontal Builders who could have useful insight, maybe a person handling claims and/or another person involved on site in Caleb’s team. They need a meeting to include Fiona and himself, along with all the other identified people at Horizontal with insight into what could have gone wrong. Gabriel walks over to Oliver’s office and explains where they stand. Oliver adds this as another task and puts it into “In Progress”, Gabriel puts his task, to identify the people, into “Wait”.

Later, when Fiona and Gabriel return to the board, Gabriel assigns himself a new card, Oliver joins them noting that he hasn’t heard back yet about the proposed dates, so they move the card to the “Wait” column, as they cannot do anything from their side at the moment and are rather just waiting for external input.

Two days later, they have the meeting with the client’s key persons and Gabriel moves the card “Identify the people able to provide detailed information on relevant issues and interview them” back to “In Progress”, with Gabriel taking ownership and working on the last Task: summarizing what they have learnt. Once he’s done, he adds a small Post-it with Fiona’s name and puts the card back to “To Do”, adding another Post-it: “@Fiona: please check whether you have something to add to my notes”.

Later when Fiona goes back to the board and is happy to see the work has progressed this far. She picks the card Gabriel has left her and opens his file to start her review. After adding a few minor details, she goes back to the board and moves the card to the “Done” column.

The next morning when the whole team meets, they explain to Alice and Oliver how this example card has moved and Fiona notes for the whole team’s transparency that this Item is done. They find that the process is more formalized than their traditional e-mail messages, but it certainly helps the transparency and gives the team members more flexibility.

Example

In this example we show you how the workflow of a card can look like:

Step 1: A card describing an Item is added to the Backlog.

Step 2: During their weekly team meeting, the team checks all required details are on the cards and puts it to “To Do” to be worked on within this Sprint.

Step 3: Fiona pulls the card out of the “To Do” and works on the Item.

Step 4: After Fiona has finished the task, she assigns it to the Alice, the attorney responsible, for review, and moves it to “To Do”.

Step 5: When Alice starts working on the card, she pulls it into “In Progress”.

Step 6: Alice asks the client’s project manager Bob for confirmation of facts and moves the card to “Wait” for the time waiting for a reply.

Step 7: When the reply from Bob comes in, Alice pulls the card back to “In Progress” and makes the required changes. Step 8: Once these are finished, Alice moves the card into “Done”.

Besides what we have already seen, there are some considerations we deem relevant, especially in a law firm setting:

• Define a process/workflow for how cards move across the board and if the cards can be taken out of the Backlog by the team members (pull system) or if they are assigned to them (push system).

• It also needs to be defined who can add cards to the board (e.g. just the attorney, the client), and who can break up a card into multiple ones. This can be the case when an Item is well-enough defined to be split up into individual tasks or when working with separate Kanban boards for the client and within the attorney’s team, the client-facing cards might be split up into multiple cards/tasks internally.

• The Work-in-Progress-Limit means how many cards any one team member can have in the “In Progress” column and keeps the members from starting too many Elements. In general, this limit should be fixed and only changed if the team finds that a different limit would make more sense in general or for a specific period. If another person/event is blocking the progress, it should be moved into the “Wait” column.

• Finally, it can be helpful to make two separate boards for the same project where one is client-facing and the other law firm internal. The Elements will be largely identical but might be split up into multiple cards internally.

• If you would like to leverage essentials of this but are not comfortable with the board or want to work electronically without a dedicated tool, you can use a simple document as Kanban Board. Change the format and move the Items into a Backlog Table, which can even be a text document or table. You will find a template at the end of this Chapter.

Story

Clarifying responsibilities and limits on the board

Gabriel, who finds he’s very much enjoying reading about the Agile methodology and being able to apply it in real life, is currently reading about practical considerations when working in an office setting with Kanban. Based on that, he brings up two topics: one very brief suggestion and one somewhat broader decision point.

First, he suggests to clearly state something that they were already doing. They should define the work-in-progress-limit. He noted that at they each worked on one or maximum two topics at once. Fiona and Alice are quick to agree on this; it clearly makes sense, although Alice notes that she might not always keep this fully up to date when she juggles many topics. She commits to try, though, noting that they should otherwise possibly introduce a soft limit for her so she can put everything she’s working on in the respective column so that the team has a better understanding of the overall work. Oliver’s reaction is similar: he has so many small topics that this might be a challenge. They all acknowledge that this is more a matter of updating the board than of doing many things at once, though. Small topics should be finished fast, and if they can’t proceed because of external factors, the respective card will be moved into “Wait”.

Gabriel’s second suggestion is to discuss responsibilities regarding the cards. They already had a few thoughts about that when discussing Acceptance Criteria. But they did not discuss this in a broader manner. They somehow assume that the senior colleagues, possibly sometimes Fiona, in general Alice, would need to confirm that an Item is “Done”. But that’s about it. Gabriel suggested to discuss the responsibilities throughout the lifecycle of Elements. Before looking at the nitty-gritty, Gabriel suggests a general approach. He recommends that they should use a pull system in which each team member takes up work when capacity is available. Alice has doubts initially as she explains that not everybody in the team might have sufficient overview to set the priorities as they should be. A few arguments back and forth later, Alice is fine with a setting in which the cards are jointly looked at regularly and discussed in the team, whilst in general being a pull system. Gabriel convinced her that it would not make sense for the team members to wait for her to be back and idle in between, rather do something useful. But that’s where “Wait” comes in, after all.

Similarly, for adding cards, Gabriel suggests that everybody should be free to add to the back-log while acknowledging that in most cases it would be for the team or a senior member to decode that the card is placed in the “To Do”, unless it’s just derived from the current work. That would enable the senior colleagues or the overall team to set the priorities.

Example

Kanban Board

Backlog Table (instead of or in addition to a Kanban Board)

Template

Kanban Board

Backlog Table (instead of or in addition to a Kanban Board)

At the end of a Sprint, the finished work is reviewed with the stakeholders and discussed in a (Sprint) Review. The team works together with the stakeholders to gather feedback on the work product as the outcome of the Sprint. The Review helps to show deviations from expectations, where adaptations are needed, and where requirements were not communicated clearly enough. For example, this may include the structure or formatting of the output (e.g. a legal document such as a contract) but also topics the client misses or sees as superfluous. At the same time, the Backlog can be changed to adapt to new requirements.

Especially when working with clients, the requirements of what is needed can change over the course of a project, like a trial. Within the team of a law firm, the Review helps you communicate better what you expect from your team and force yourself, as the attorney responsible, to define what is important to you in any Item. This may be anything from the formatting of legal documents to the way a contract is structured.

Story

Claims everywhere

After getting Alice’s approval for the draft, Fiona sends Eric, owner and boss of Eric’s Electro Builders, a letter detailing the claims Horizontal Builders have based—thereby finishing another Item (“Write the claim letter”). As Caleb’s project management was professional, she is able to refer to delay notices and similar formalised communication between Horizontal Builders as general contractor and Eric’s Electro Builders as subcontractor and counterparty. She equally outlines the potential damages in case of further delays.

The reply comes swiftly. Eric is willing to meet, initially without legal support by himself, but he announces that he’d contest the claims and even bring counterclaims to the table. Informing their client Bob, Fiona tasks Oliver with organising the meeting, including Caleb, Eric and Fiona but no one else from the team, given that they do not want to make this initial meeting too big.

Besides discovering that Eric also deemed to have claims, they quickly find that Eric, too, seems to have an interest in advancing quickly. The meeting is scheduled in two days.

During their meeting, Eric extensively describes where he deemed that the project was off plan, namely the HVAC company, who was directly contracted by Bob’s builders. According to Eric, they messed with the sub-distribution cabinets, both in the central infrastructure area of the building as well as in two localised places. The last topic of the meeting is particularly sensitive as Eric’s Electro Builders is responsible for the overall safety and would thus need to recheck everything. That will unavoidably lead to delays and an increase in cost in the project—both not Eric’s responsibility. He estimates the additional cost at 30,000 Euros.

Bob presents Horizontal Builder’s position, notes that he is surprised as the contractors are all companies they have been working with for years, but that they will certainly consider Eric’s version. He asks Eric whether he has material to underline his position. Eric promises to provide them in due course.

After Eric leaves, they ask their junior associate Gabriel to join them to discuss their findings, asking him to start creating Tasks based on the meeting minutes which Fiona writes. Gabriel, who had read eagerly about Agile, suggests that this would usually be part of a Review meeting, so they first have a look back at the finished work to have a joint starting point. Fiona briefly presents the Items that have been completed and Alice agrees that the work was delivered as needed but that the fact-finding Epic might need to be added to, based on Eric’s information. Alice expressly asks their client for feedback about the work outcome provided so far as part of the Agile methods, but it still feels a bit awkward to them. So far, the client is happy, but both Bob and Caleb are curious to get a better understanding of whether Eric’s claim has any merit and if it will surface something they previously missed. Especially the HVAC company’s alleged activity seems somewhat strange to Caleb. The team remembers they have an overview of all relevant persons involved, the stakeholder map, and that they should update it based on the latest findings.

Example

Template

In Agile working, there are specific meetings that are core components to ensure the teams are working together well and progress is made and checked, as well as how they could improve their Agile process and collaboration.

Because of the Sprint’s self-contained nature, it is essential to plan it and estimate what can reliably be achieved within the Sprint. This Planning is the first thing that happens in a new Sprint and deals with the selection of which Items will be executed in this Sprint and what they contain. Sprint Planning is often split up into what will be done in a Sprint (“Phase 1”) and once that is defined, how it will be done (“Phase 2”), but for our purposes both will be done together in one meeting. There needs to be a common understanding what is part of a certain Item and what isn’t, therefore the second phase is used to define the actual tasks contained in an Item. Whilst the Product Owner defines the Item, the actual tasks are added in this phase because the subject-matter expertise of the team is needed.

Planning meetings can also include the client as a guest, which is useful when the planning involves a Sprint that leads up and prepares for a big milestone, like a trial or contract negotiation. This way, when the Items of the Sprint are discussed, the prerequisites (the how) can be assessed together with the client. This can add more transparency both within the team as well as with the client, as the crucial questions What and How are addressed openly.

Of course, it might not always be possible to define every single detail of what needs to be done in a Sprint right at the start. A Sprint can evolve as necessary. This means adding additional Items or reprioritising as needed. Therefore, it is useful to not fill a Sprint completely, but rather only planning for about 70-80% of the capacity the team estimates. This way there will always be room to deal with anything unplanned. Anything that does not fit the Sprint can be done in a later Sprint—thus making clear priorities a key factor.

Story

Of waterfalls and iterative work

Over the next few days, our team is busy gathering facts of the claim and potential evidence. By the next team meeting, they feel confident enough they have a decent basis to start into the legal assessment of the case. Parallel to that work, they have already started to gather potential legal bases for a claim, so they can then match this and, on that basis, clarify their evaluation and be ready to discuss it with their client Bob and his project manager Caleb.

While the legal process itself was advancing well, Alice feels somewhat rushed because several other unexpected topics came up that she needed to urgently deal with. She feels that adding several Agile meetings to her days would not help her at this point. With that in mind, she asks the team whether they need to take this step now and if so, if these will really require her. In one of the Agile workbooks she had purchased, Fiona noticed a remark that you could invite external participants to a planning meeting where it made sense. They could try to just have the client and the Agile planning meetings together; she’d just think through how to present this to the client and give it context. Possibly, they could even make this standard by seeking to have a regular exchange with the client before important events (e.g. court hearings). This can mirror the phases of the planning: Phase 1 of the planning would be together with the client as external participant where they determine what would be done. In Phase 2 they will define how the work is done internal. She mulls over how that would go together with their planning meeting, and even combine it with their usual weekly team meetings.

After the meeting, Fiona and Gabriel go to their favourite lunch place around the corner and dive right into how they would create a setting to inform their client about their assessment and how to draw the line to planning. Gabriel notes they can present the planning part as part of a continuous drive of their law firm to innovate and do three things in one: summarise the facts and their legal assessment to the client, describe their work, and use Agile Elements and Kanban to plan their next steps, together with their client. Alice is delighted as it saves her from having yet another meeting and she very much likes the idea of showing the client that their law firm is leveraging modern methodologies in a way that makes sense for the projects.

They invite the client to their office for an alignment on the next steps, informing him it will also be their Agile planning meeting. Bob is happy to see the matter progress but sceptical about the format. As building needs stringent planning, top-down—or as software and Agile people would call it, waterfall planning—he is not a big fan of what he has heard about Agile. Yet, Bob acknowledges that that the fields are different and appreciates their striving for continuous improvement.

In the meeting, Bob clarifies that he wants to push Eric once again to finally deliver or to support handover to a different company because of the overall delay. During planning they agree to address a first settlement discussion with the counterparty in the week’s work, so the legal team hears the counterparty’s position. The team and their client align on the paths that would work well for Horizontal Builders. Bob noted that he would be evidently open to consider alternative proposals that might come up in the discussion with the counterparty.

Example

In our example case, the first planning would be what to include in the claim letter:

Template

We would like to thank the following people for their valued feedback and input:

• Isabelle Creutzburg

• Martina Hackl

• Kai Jacob

• Anita Lamprecht

• Jonathan Lourie

• Jutta Löwe

• Julia Luksan

• Rainer Markfort

• Esther Sowka

Hold This book is the result of a project at Liquid Legal Institute e.V. We are especially thankful for the platform and the support the Liquid Legal Institute provided, which gave us the opportunity to work on this book.

Special thanks go to Jonathan Bisset, who edited the book (including—but not limited to— this sentence).

• Acceptance Criteria, see Chapter 4.6

• Accountability, see Chapter 2.2

• Dailies, see Daily Stand-Ups

• Daily Stand-Ups, see Chapter 6.1

• DEEP, see Items Chapter 4.3

• Definition of Done, see Chapter 4.8

• Definition of Ready, see Chapter 4.7

• DoD, see Definition of Done

• DoR, see Definition of Ready

• Element, see Chapter 4

• Epic, see Chapter 4.2

• Estimate, see Chapter 4.3

• Goal, see Chapter 4.1

• INVEST, see Chapter 4.3

• Item, see Chapter 4.3

• Kanban, see Chapter 5

• Kanban Board, see Chapter 5.1

• Meetings, see Chapter 6

• Mindset, see Chapter 2.1

• Planning, see Chapter 6.2

• Planning Meetings, see Planning

• Product Owner, see Chapter 2.2.2

• Retrospective, see Chapter 6.4

• Reviews, see Chapter 6.3

• Role, see Chapter 2.2

• Scrum Master, see Chapter 2.2.3

• Sprint, Chapters 3.1 and 6.5

• Sprint Planning, see Planning

• Stakeholder, see Chapter 2.4

• Stand-Ups, see Daily Stand-Ups

• Swim lanes, see Chapter 5.4.2

• Task, see Chapter 4.4

• User Story, see Chapter 4.5

Items are next broken down into executable Tasks. Depending on which tool you use to visualize Items and Tasks, Tasks can be a checklist in an Item, sub-Items, or separate cards on a Kanban Board (Chapter 5.1). The Goal of tasks is to make Items easier to handle during a Sprint. A Task usually has a size that allows it to be done within one day.

Story

Getting Busy

We have so many Elements described and we’re not yet at the fi nish line, thinks Fiona, wanting to get going on the legal work of the case. Yet, the weeks need to be planned. And plan they do. They find that the description of the tasks was somewhat easier, as they are very near to the actual work to be done. The different sizes of Items trigger questions for our legal team, though: do they need to break down all Items into Tasks or would they leave smaller Items as-is? They initially just seek to avoid doubling the work and therefore only break down tasks that are too big to be addressed at once.

Luckily, they remember that they can start with the fi rst Epics/Items as they occur and do not need to defi ne everything in detail at the start—after all, it wouldn’t be Agile if you knew everything at the start. Phew!

Now that they have arrived at the most detailed Element, they are happy to start their actual work. They quickly agree on who will start with which task. They ask their team’s organizing talent, Oliver, to arrange another meeting with the client’s project manager, Caleb, and ask him if there are key people that need to be involved. Senior associate Fiona will take the task of creating an overview of all involved parties, but she still has mixed feelings about their process. It is an interesting experience, yet they could have started earlier without it, likely with a similar allocation of Tasks. Gabriel will need to do more preparation for their Agile methods—something they certainly need as a fresh team, but which is not part of the core work they need to do for a client.

Example

Item 2: Draw an overview of all parties involved in the case

Tasks:

• Organise a meeting with the client.

• Gather a list of all parties (based on discussion with client).

• For every party, note their function.

• Sketch their relations.

• For each party, note their position.

• Confirm the details with client.

• Establish their interest in the case.

• Establish their influence on the case.

• Update the stakeholder map accordingly.

Template

Item: ...

Title: ...

Retrospectives (or “Retros”) are used to improve the process, the collaboration, and the tools. The team members discuss what they liked, what they learned, and what they lacked. The outcome of a Retrospective should be an improvement of the current process.

Usually, the Retrospective comes right after the Review and concludes a Sprint.

As an attorney, improving the way you work within your team as well as with your client is crucial. Due to the big impact a Retrospective can have, it should be a standard meeting at the end of every Sprint, but at minimum at the end of bigger or new projects. Within your team in the firm, asking yourselves these questions is part of the continuous improvement process. For this, a separate Retrospective-like meeting can be held on a monthly or quarterly basis.

Story

Learning along the way

As they are working in litigation, Alice’s team is one of the teams in Lawyering & Co. that has quite a lot of external meetings, hearings, and court dates. As most of these are scheduled without much of their input, finding spots to meet internally is tough. The next time the whole team will be together is their regular team meeting, which they always try to protect as it feels important to have at least one occasion per week during which all of them meet at the same time.

Even before they started their meeting, Alice is eager to hear how their Agile efforts are doing. When the topic of improving the processes comes up, they discuss if they should add a “Retrospective” topic to their agenda, as Agile has a distinct meeting to review the process, collaboration, interaction, and tools—with the Goal to learn and improve. They quickly decide that it would have to suffice to hold this meeting once a month for a start, scheduling it with the second team meeting of the month. To hold it once per Sprint, as Agile methodology would recommend, would really hurt their scheduling. Once they had done a few Retrospectives, they could reassess their frequency.

Practically, as they are currently in a setup where Alice is working on a few urgent topics and Fiona and Gabriel are working on the Horizontal Builder’s case, both with some pragmatic support by Oliver, their update is rather quick, and they turn to the Agile parts. The resumé was quite quick: they feel energetic, Agile looks promising, but there are ample topics to learn and improve on. They are doing ok with the work on the Elements each of them took, albeit struggling from time to time on detailing them out as expected in Agile—they hope that with practice, mastery would follow. Having not had many Agile meetings, they still agree to include them as part of their team meeting agenda, which they will extend to accommodate the new topics. Yet, they continue to mull over what they would do with the actual cases, especially the review and planning and corresponding interactions with their clients.

Then their first Retrospective comes around, the team sits down and discusses what had worked well for them, what hadn’t, and what they wanted to improve, noting it down in the relevant document.

Example

Template

Dailies or Daily Stand-Ups are—as their name suggests—meetings that the team holds every day. They’re intended to be very short, usually 15 minutes, for that reason it is common that the participants hold this meeting standing up.

The Daily serves a specific purpose: it is an opportunity for the team to check if they are on the right track towards their Goals and to identify where collaboration is needed. The idea is to identify problems (not solve them!). By jointly identifying the issues and by then briefly discussing who will address what or who might make a connection that might be able to help, the Dailies help ensuring the right people are collaborating throughout the day. Any impediments that arise are made transparent, so the right people can be brought together to deal with it. Fundamentally, it is an opportunity to inspect and adapt at the most basic, operational level.

The typical three questions asked in each Daily are:

• What have I accomplished since the last Daily?

• What am I going to do until the next Daily?

• What do I need to achieve my goals?

Within the law firm or within your team, it makes sense to have a short daily meeting to check in with everyone. Even if these meetings within a team aren’t held each day, asking the typical questions of a daily can be a very useful tool in each meeting setting.

It is important to note that a Daily can quickly turn into a status report meeting—which is not the intention. It is crucial to have the team be in control, and not some manager/partner to avoid micromanagement. Everybody who participates in a Daily does so in the role of a team member, contributing to the work of the team.

Practice Tip: What if the frequency does not match your needs?

The frequency might indeed need some adaptation to your needs. We suggest starting with a daily meeting and reduce the number of meetings if necessary.

While everybody should aim at being available, if possible, there is no strict duty to attend. If a team member in a court hearing, on leave, or similar, the other team members meet. As this is not a status report meeting, the approach works even if not everybody is available every day. The team should, however, keep the overall attendance rate high to avoid devaluation of the Daily.

Practice Tip: Choosing the right setting.

Think about the right setting for your Agile meetings. Include room and tools into your considerations. A few practical insights from experience:

• The room should be suited for a quick get-together rather than being a room to meet comfortably for longer times. People should feel comfortable but should not be invited to drag out the length of the meeting.

• Sometimes it can be useful to have the Kanban board or another visualisation tool at hand but note not to reiterate any status in the Dailies. Focus on the three questions presented.

• Depending on the team setting, a remote or hybrid setting may be required. If you go hybrid, take care that the team members who are not on site feel equally integrated, especially in cases in which certain team members always work remotely.

Story

Doing it day in and day out

As a small team, they do not to have very clear habits regarding their work organisation. They take pride in flexibility, so they worked and met as they deemed fit for their current needs. It worked well for them up to now, both in their own team as well as in interaction with other teams and practice groups in the firm Lawyering & Co.

Alice and her team wonder whether they can bring their setup to the next level. In their Agile books, they read that a formalized organisational setup can help with outcomes. Would a structured setting even help creative work? Our team is willing to run a little experiment and learn whether it does or not.

They know that typical Agile setups feature several meetings, but they decide to first implement one of them and then, when they have had a few days to get accustomed to it, see how to do with the rest. They chose to start with Dailies. Instead of just spontaneously meeting, they would come together at a pre-defined time to exchange the key information. Clearly that does not keep them from getting in touch in-between, but it would channel the energies so every one of them would have fewer distractions. They discuss the best timing, which was not easy given they had court hearings, and agree to start with a brief exchange in the morning, at 8:45, which is usually before the hearings. They will hold this meeting in front of their Kanban board so they can refer to it if needed. If somebody would be unavailable due to appointments, they decide to implement an option to participate remotely, but take a note to ask some experienced person whether that made sense from a methodological perspective.

Knowing that practice makes mastery, they agree that every single one of them would seek to remind the team if they deviated from the very narrow three topics determined to be discussed. To facilitate that, Fiona suggests writing down the three questions and that one of them would take notes during the meeting.

Gabriel—as Scrum Master—is tasked with moderating the Daily, leading the team through the questions. They decide to go through it question by question to have the topics grouped. For the accomplishments, Alice notes that she was finally able to finish implementation of a real estate litigation she led for an overseas client, so she doesn’t have an update for our case at hand. The others do not have any big updates but are progressing happily, Item by Item. Briefly touching the question of what was planned for the day, Fiona and Gabriel plan to finalise the overview of all parties and complete the list of relevant people for detailed information. Oliver is primarily busy on other cases at the current time and expects the same for the following day. Alice adds that she will work on the ongoing cases for existing clients. When Gabriel invites everyone to share what they’d need from the team, Oliver reminds them to confirm the setting for the planned meeting with Caleb and his team and Fiona says that she would like to have Alice’s opinion on the status on some Items so that she can declare them as done. They briefly check that the Kanban board is up-to-date and move one forgotten card along to reflect its status. It passes very quickly and as they finish their first Daily at 8:57, three minutes early, they are eager to start the day’s work because they feel that their progress is more visible with their new Kanban board.

Example

Template

An overview of all templates, as well as FAQ and further information can be found here:

These meetings occur at well-defined points in time, which could look as follows:

Story

Building habits

Would they do these meetings every week, Alice asks their colleagues, when they meet. Given the different timing requirements of the legal proceedings they ran, they decide that a rather short iteration interval would be advantageous, so they decide to do exactly that: weekly Sprints. Regularity will help them form their habits and the litigation often evolved so dynamically that a weekly planning would come in handy.

For the time being, the team sets up the following schedule of meetings: their team meeting will be extended from an hour to an hour and a half, and they’d have a quick Review, Planning and, once a month, Retrospective (all short) as well. If needed, the client could join the Review part, but often that might be a separate appointment.

As Agile methodology intends, they would continuously revisit their plan and adapt, if needed.

Baltasar Cevc is an attorney, entrepreneur and technology and innovation enthusiast with years of professional experience from start-ups, medium-sized businesses to large corporations. His passion lies at the interface of IT and law as well as on the improvement of work methodology in the legal industry. He loves to work at eye level with clients, especially in the fields of Cloud and AI, including the associated data protection questions. His previous employment as an IT expert gives him a complementary perspective. This enables him to combine the legal, technical, and business perspectives to develop practical and pragmatic solutions.

About the Speaker

Due to the fact that this Roundtable took place shortly before Christmas, this session followed a slightly different approach.

Several speakers shared insight on their topics of expertise.

Abstract

The goal of this session was to develop a common understanding of what Law Firm Operations at the LLI entails.

We talked about the following topics:

Story

Epilogue

Up to new horizons of the case.

As it is very common in complex projects, further factfinding revealed that, albeit professional people worked at Horizontal Builders and their subcontractors, project management is never perfect and certain issues were indeed not Eric’s fault. The counterclaims partially had a basis, but Eric’s company also did not perform as expected and the counterclaims were much smaller than the claims. After thorough discussions, Eric accepted that there was a valid basis for about 75% of the claim after discounting for the valid counterclaims. In the end, they settled for a payment of 55%, to be paid in instalments. It was overall the commercially better option than pursuing a claim one could not execute upon.

In the last review meeting with Bob and Caleb their client pointed out the high professionality due to their Agile setup. They were satisfied with the outcome and would likely do the next litigation with Alice’s team again.

Same but different—how Lawyering & Co. looks after months of Agile transformation

Rather unsurprisingly, deciding on weekly Agile meetings was not where our heroes stopped. They pushed for both a methodological improvement as well as a commercially better out- come for their client, Horizontal Builders Ltd, as well as quality control. About a year after they started, the little team we’ve accompanied works in a fully Agile setup, and together with the law firm’s IT department, are currently testing software tools to support the law firm’s Agile work. They are primarily focusing on how to digitize Kanban, as they have found that is one of the most powerful tools for them.

The team’s normal team meeting also took on the form of Reviews and Plannings as these methods were becoming second nature to them.

Further teams followed suit and turned to Agile work, which is starting to be an argument to attract good talent as well as a selling point to prospective clients. Oliver and Igor are probably the only non-attorneys to know every single person in the firm as they are happy to share their experience and help others establish good working practices. The same goes for Gabriel as junior associate.

To make their endeavours more effective, Alice hired an Agile coach whom Sara recommended. The coach is answering questions and helps them in improving their methodology by regularly questioning their approaches.

On Oliver’s suggestion, Lawyering & Co.’s Newcity office introduced monthly Agile lunches, which all interested staff can join to discuss how the work in the firm can be improved, to ask questions and hear insights from colleagues and to share best practices. The attendance is growing so quickly, that he is already considering holding them every other week.

As a side effect, the everyday exchange across teams of the firm has considerably improved. Invitations to speak at conferences about the firm’s organisational transformation started trickling in and became subject of intense discussion at one of the Agile lunches, both regarding whether these engagements were worth the effort and as to who could be good speaker. Several options were considered and the one that raised least opposition was that it was worth trying out such engagements for a year and then evaluate. There was quick consensus that the firm should only accept engagements that allowed for two speakers to co-present and that these should be of diverse background, i.e. one person with legal background and one from a different function as that itself was a strong management of a good team culture which Agile needs.

A key observation at one of the regular visitors to the Agile lunches was that Lawyering & Co. was radically different from how it used to be a year ago, still yet the same law firm. It was their pre-existing culture that allowed Agile to be embraced so quickly as it was already open and positive. This culture is still at the very heart of the firm. The focus on quality and on client needs was only helped by the new methods. What has changed is the way they implemented their work.

They would describe this change as an evolution because such changes are rarely radical. The firm has found the right pace to adapt.

About the Speaker

Abstract

Lena offered valuable insights on identifying and integrating the optimal AI tools for legal applications. She explained the management of pilot projects and discussed the essential metrics for evaluating the effectiveness of AI technologies in legal practices.

The Roundtable takes place every month on MS Teams.

About the speaker

Abstract

Chris gave an insightful input on general problems he faces as a consultant that supports law firms in navigating change. He gave an overview and thereby helped the group dive deeper into more specific topics.

You now have everything that you need to start your first Agile working setup.

If you find it difficult to get started, we suggest asking yourself what the most relevant problems that you are experiencing right now are and building a deep understanding of these issues. Kanban on its own can be a useful tool to help with that, since it can likely make things visible that are not working well.

It’s all about figuring out what you want to change and building around that by picking things that you believe can help in your specific situation and then validating that assumption. After all, Agile is all about assessing and adapting. This is also why we suggest establishing how you want to organise your work and processes before looking at tools. Build the solution that works for you first and then find the right tool to scale it. Not the other way around.

Of course, once you’ve worked through this book, there is much more to discover in the realm of Agile working. As further steps we would suggest taking a closer look at Agile topics like estimation or self-managing teams. There are lots of books and communities out there, so it should be easy to find relevant literature or like-minded people (like, for example, at the Liquid Legal Institute) to discuss with. Of course, you can always get in touch with each of us if you have more questions.

Do you want to support this initiative?

tba