Should a Kanban board show who is doing what?

Question

Let's suppose that a team is developing a software product. Should we indicate assignees on Kanban cards? Isn't it an anti-pattern in Kanban?

Answer 1

Why would this be an anti-pattern? One of the Kanban principles is about visualizing the workflow. Being an Agile practices, it's also about transparency. Look at the board and you have an image of what's going on. That means what work is in progress and - if you have an assignee on the card - who is working on the items.

If you find it useful, you can add an assignee. If it's not useful, or it's too much hastle to keep this field up to date (assign, re-assign, more people working on the same card, etc) then don't add it. Either way is fine, and neither way is wrong.

Answer 2

TL;DR

If you're going to do it at all, you might have people assign themselves to a work item to indicate who pulled it. No one should ever be assigning work to individuals other than themselves in any well-respected agile framework.

However, while generally an anti-pattern, taking the role of card handler/coordinator is certainly acceptable in a pull-queue system like Kanban. However, it should be for some useful purpose of value to the team other than to reduce the need for collaboration or communication! If the primary goal is to reduce the need for people to talk with one another, it's a clear violation of core agile principles even if it's not (strictly speaking) a violation of the Kanban framework's principles.

Analysis

Kanban is not prescriptive about the contents of Kanban cards. The very term "assignee" is non-agile, in that it explicitly assigns work to a person, rather than a team or process. Assigning work to individuals rarely invites collective ownership or collaboration. Therefore, the use of assignees can certainly be considered an anti-pattern.

Within a single "two-pizza team," the use of assignees is almost certainly the wrong thing to do because it invites work silos and "not my job" thinking. However, having a readily-identifiable point of contact for work items in very large teams or enterprise-scale processes is occasionally necessary to reduce cognitive load and muda related to continuously tracking down the right people to talk with.

In an agile or scaled agile context, as long as everyone knows who's working on what (whether at the team or individual level) there's never a need for attaching names to work items. For example, if someone on the widget embiggening team needs to collaborate or coordinate with the frobnitz ensmallening group, it's easy enough to ask someone on the other team who they can discuss it with. If no one knows, then the Scrum Masters (or equivalent roles) can address this as a blocker or process issue.

Recommendations

Figure out why you want to do this in the first place. Some questions to ask the team include:

1. What problems are we trying to solve with this approach?
2. What is the impact (positive or negative) on flow and cycle time that may stem from tying work items to individuals?
3. How will the team evaluate the cost/benefit of tracking this level of detail?
4. What processes and procedures will be impacted by this change in workflow?
5. What tools will need to be added or modified to support this new workflow?

Every business decision is a trade-off. Tracing work down to the individual level inherently adds additional overhead to the process. It can (but not necessarily will) increase transparency and reduce "lookup time" when tracking down who's currently touching what, but whether or not that actually adds value will be very situational.

In short, doing it just to do it just creates complexity. Even doing it to create additional information at the top-level without requiring additional drill-down is of ambiguous value if this information is not an essential KPI or metric for your framework. (Hint: in Kanban, names are rarely a first-class information item, whereas roles or teams sometimes are.) Visualizing work should always provide more signal than noise!

I'd strongly recommend aligning your Kanban implementation to your process objectives, rather than creating a heavyweight process ab initio. Unless you can point to a clear performance objective tied to tracking the data, treat any additional complexity as a potential source of muda (waste) and avoid it if you can. You can always include such information at a later time if your inspect-and-adapt loop shows a real-world need for it.

Answer 3

It is certainly not an anti-pattern in Kanban. However, ideally, a card should show an "assignee" only when the card has been pulled from the Backlog or Ready column into an in-progress column.

Whether you have someone on your team "assigning work" to other team members (perhaps that is what you are referring to as an anti-pattern) or whether you have team members "pull" a card when they have capacity to work on it, the card should show who is working on it. That is an important part of the various attributes of a card visualization on a Kanban board - and pretty much all Kanban teams that I have interacted with will show who is working on each card on the board.

If there are multiple people working on a card, you might have multiple avatar stickers on the card or a group icon such as shown below -

Physical board -

Electronic board -

Whether your team members 'pull' work or have it assigned to them during a standup (or outside of it) depends on how mature and experienced they are and how comfortable they have become with Kanban principles. And also what policies you might define and make explicit as to how team members pull cards.

It should be quite possible to 'establish pull' within a reasonably short period of time where team members pull work as soon as they have the capacity to work on it, based on a set of predefined policies such as card priority, size, age (how long it has been sitting in the Ready column), etc.