Kanban boards (AKA “story boards”) are used by most Scrum, XP, and Kanban teams.

They are a kind of Big Visible Chart used to visualize the work of the team in a straightforward way.

As useful and simple as they are, in practice many are set up in ways that discourage teamwork and collaboration, ironically defeating the purpose of having self-organizating teams.

Here is a common example:

The board above has a hard-coded assumption that work is assigned and performed by individuals. It is really a vertical stack of kanban boards where each person is treated as a separate team: a layout that strains the very definition of team.

People will not work together to complete stories if they each have "their own work" to do.

There are natural consequences of such a board:

Each task or story will be subject to individual biases, blindspots, and signature errors; this results in defects and mounting technical debt

Standup meetings will be a redundant ritual, with each person waiting their turn to describe the status already shown visually on the board

Stories tend to be written and split as dependent fragments assigned according to an individual’s knowledge

Developers’ personal work load takes priority over the needs of the team

Any absence or interruption will cause one person’s work to stop, possibly jeopardizing their remaining work stream and any dependent stories

Per-person workloads increase Work-In-Progress (WIP), which damages flow

Cross-training and knowledge-sharing will be minimal or absent

In our software practice, we work to mitigate risks to software development; we call it “Anzeneering”. We have found that solo work is hazardous.

We find a lot of safety in pair programming and mob programming precisely because it brings multiple human brains, lifetime experiences, and awareness of technical and social issues to the work we do. It completes work sooner with better quality.

What if we change the board to focus on moving stories and tasks quickly to completion without segregating the efforts of individuals?

"Watch the baton, not the runners."

In order to allow self-organization, we must allow multiple people to work on any task, and allow them to switch tasks opportunistically.

We can take our first step by simply removing the per-person swim lanes

This makes the stories and their movement the primary consideration.

Who is working on this?

The problem now is that I don’t know who to talk to if I have a question or revision to a story in progress. How can we keep track?

If teams have physical boards, team members will often write their initials on small-sized sticky notes and attach them to stories.

In some cases, they clip small pictures of themselves to the story they’re working on.

The “attached faces” idea is duplicated by our online kanban board (presented with some client names redacted):

If your tool insists on individual assignment, you may create “fake” users to represent groups (“Team A”, “Team B”) and keep track of group membership with a more physical mechanism in your work area:

If you need to know about authorship in the future (perhaps for audits), then be sure to list the group members names in version control where you track authorship and changes already.

If we have many members of the team involved in a change then there is always someone around who was one of the original authors, and recording authorship becomes far less important.

In summary