5.5. Further Tips
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
Draw an overview of all
parties involved in the
case, including their position
and relevance
Assignee: Fiona
Due: 14/04/2024
Identify the people able
to provide detailed information
Assignee: Gabriel
Due: 25/03/2024
Set up client meeting
Assignee: Oliver
Due: 01/04/2024
Backlog Table (instead of or in addition to a Kanban Board)
Template
Kanban Board
Title:
Assignee:
Due:
Backlog Table (instead of or in addition to a Kanban Board)
Last updated
