The Most Minimal Kanban

Sometimes I feel overwhelmed trying to manage everything I have to do. Lists work okay if they're short, but grow out of control and fuel new anxieties: am I failing to stay on top of things? Writing a daily agenda lets me get a ton of things done, but burns me out; I feel like I'm a robot executing my past plans. As an alternative, I've started experimenting with kanban as a more humane way to manage my long-running tasks.

Kanban is a process management approach which focuses on creating a smooth flow of work items through a process. Work items are tasks like writing an article or adding a software feature. It's common to use a kanban board to visualize the way work items move through the kanban process. A kanban board has a number of columns, which match stages of some process. When writing an article, the work item might move from ideation, to research, to draft, to editing, and finally to publishing and distribution.

Many software solutions exist to implement kanban, such as Trello to Obsidian Kanban or the minimal kanban.bash.

I've used all three tools, but found them lacking. The main reason is that they require context switching. I spend most of my time with a computer on the command line, either editing text in Neovim or running code with some interpreter. Switching to a browser and logging into a company portal takes long enough to break my focus on my current task.

The other problem with most kanban software is the use of non-portable data formats. Trello supports JSON and CSV export, but the exported data isn't usable in other software. kanban.bash uses a hidden folder with CSV data, but makes it hard to centrally manage more than a single kanban board. Obsidian Kanban uses Markdown, but won't display as a kanban without the plugin - locking you into using Obsidian.

I wanted an approach which I could use from the command line, with a portable data format. To do this I decided on a couple of design guidelines:

• No complex scripting or programming: every operation must be possible with popular Linux tools. This is to avoid lock-in and make it simple to prototype. Writing a complex program defeats the point of the exercise.
• Any data stored must be plain-text and integrated into a document. This is because introducing a database, custom markdown extensions, or even a csv file makes backup and file management more complex. It also reduces interoperability with normal file system operations and makes it harder to share my files with other people.

A Minimal Kanban

To build the kanban board, we can use the native layout of the file system. First, we create some folders using mkdir or our native file manager. These are the 'columns' of our kanban:

- kanban/
  - 00-icebox/
  - 01-todo/
  - 02-in-progress/
  - 03-done/
  - 04-cancelled/

Next, we create some work items inside each directory. I used markdown files but these can be any file type - they don't even need to be text files.

- kanban/
  - 00-icebox/
    - update-accounting-books.md
  - 01-todo/
    - finish-migration.md
    - write-a-paper.md
  - 02-in-progress/
  - 03-done/
  - 04-cancelled/

When we want to update a work item's status, we just move the file. For example, moving write-a-paper.md to in-progress:

- kanban/
  - 00-icebox/
    - update-accounting-books.md
  - 01-todo/
  - 02-in-progress/
    - finish-migration.md
    - write-a-paper.md
  - 03-done/
  - 04-cancelled/

This approach was inspired by my very brief experience working in video production. We'd lay out video clips according to which stage of the process they were at, with a folder structure like:

- project
  - 00-rushes
  - 01-scenes
  - 02-videos

As is common in the video production industry, we used MacOS on all our editing machines. MacOS Finder has Miller Columns as a first-order feature, and they're a great way to visualise this type of workflow. But any file manager with a tree or column view can be used, on any operating system. To prove it, here's some Linux examples. For the GUI, I use Elementary Files (aka Marlin; Pantheon Files) which is very similar to Finder.

Kanban Gallery

Using the CLI and tree is the most powerful option, but requires familiarity with working on a terminal.

TUI tools like ranger can be a good compromise between ease of use and power.

Miller Columns are helpful when one or more columns have a large number of work items.

Tree view is helpful to see the overall structure of the kanban.

Limitations

What we built is a minimal software implementation of a kanban board, which means that it doesn't have the niceties of a conventional tool. There are two major limitations which are worth mentioning.

Work items have no sort order

Most file systems have no concept of a 'sort order' in the file system, and sorting by other file system attributes (like date modified) is probably not what we want. This is problematic if you want to use the kanban for managing a Scrum backlog, which depends on prioritizing different work items against each other.

The easiest way to work around this is to break from pure scrum by introducing a 'prioritized' or 'todo' column. This column should contain a smaller number of work items than the product backlog; at least as many as the sprint backlog. In practice, I find that product backlogs are often used this way, because only the top 20 or so items are prioritized.

Another way we can work around the sort order problem is by using a number prefix for each work item (e.g. 00-my-cool-work-item.md). Doing this manually is tedious, and the natural solution is to write a quick script for it. But under my self-imposed restrictions, this counts as programming and it's not allowed.

Work items have no metadata

Depending on your perspective, this could be a good or a bad thing. By not having metadata as part of our kanban, we avoid tying the kanban to any particular file type. We also avoid getting distracted by add-ons like story points, tags, and other shinies we may not need.

On the other hand, we can only tell the contents of a work item by its file name, and any data we want to surface must be part of the file name. There's no real traceability unless we use very granular version control / backup against the kanban. That makes using this approach for process optimization - one of the main goals of kanban - more challenging.

Here is a short list of common features that cannot be implemented without work item, column, or board level metadata:

• Work-in-progress limits
• Work item history
• Readable work item names and descriptions
• Story points
• People assigned to work on the work item
• Due dates, scheduling

Of course, if our work items are text files, these extra features can live in the body of each work item, but this will involve micromanaging the human kanban process.

Other features are possible but much less convenient than in dedicated kanban software:

• Sort order (see above)
• Tagging work items

This kind of metadata would be pretty easy to script using yq --front-matter and some other bash commands, but that contradicts my no-programming rule.

Even with these restrictions, this approach is probably fine for a small personal kanban. It might also be appropriate for an environment with extreme limitations, like a locked-down and airgapped server.

But for team and professional use, our design restrictions are too severe.

Minimalism and Compromise

My motivation for trying this approach was how overbuilt many kanban applications are, and how poorly they fit into a CLI-based workflow. In other words it was guided by a minimalist design approach.

As we found, using the file system as a kanban board works, but comes with many compromises.

In other fields, the most extreme examples of minimalism are notable, but not necessarily sensitive to most people's tastes. For example, see the architecture of Mihes van der Rohe, which was described as 'cold, barren design' even when it was at its most popular.

An oft-mocked example of minimalism in tech is the Linux cult of hyper-efficiency. It's possible to run a Linux installation from under 100mb of disk space, but only if you're willing to work from a CLI all the time and connect to the internet via a TUI. Which is a bit niche.

This level of minimalism in design and engineering mostly belongs to academia, hacker culture, and art projects. Minimalism is a good guiding light but needs to be tempered by humanism. We need to make some compromises to people's needs and expectations; even Mies van der Rohe needed to find clients willing to pay for his approach to architecture.

I think a good way to find compromise between minimalist and humanist design is to reduce the complexity of a design as much as possible, like we did with a software kanban in this article. We can then start to see which compromises we're willing to accept, and which compromises we're not. First, we deconstruct; then, we reconstruct.

For our software kanban, the restriction on programming is the main barrier to making it more user-friendly. If we relax this restriction we can keep the other: to use the file system itself as a data store. We can keep most of the benefits of our minimalist kanban while supporting most of the features that can't be implemented in that model.

Since I still want / need a kanban tool that's efficient to use and easy to back up, I went ahead and started writing the project. You can find it at codeberg/plainban.