What is technical debt?
Technical debt is the term used to describe the extra work that is created from low quality shortcuts taken to ship fast.
Typically we talk about software code as the only type of technical artifact, but really software is formalised knowledge, and knowledge artifacts can take on other forms such as a kanban itself.
Much like code, not dedicating enough time to maintain knowledge infrastructure (be it code or kanban), or simply not having the necessary skills to create quality knowledge (be it 'clean code' or 'clean kanban').
Over time, this debt can start to slow down development, as more and more time is spent working around the issues caused by the debt, rather than adding new features or fixing bugs.
A bug in software is easy to consider as you run software and encounter it in the form of a program crash. A bug in task organisation manifests as:
- Not being able to find task information easily: as it's in the wrong column or on another board (beware of changing boards for this reason)
- Not being able to change a task easily: the task specification is unclear so you don't know how to move it or you come up with hacky workarounds to 'subvert' the board
- Duplicated effort: the same item in multiple columns because it's unclear where it should go, or a label like In progress that overlaps the meaning of WIP, because WIP is not really being used.
- Out of date task info: items get left in WIP and degrade the usefulness of the board
If not tackled, this can slow your iteration just as much as buggy code can, because you end up fiddling with the board rather than making progress. This is how you make bureaucracy for yourself.
Avoiding technical debt in your GitHub Projects
The same advice for code applies:
- Don't cut corners: saving time in the short term can produce structural problems in the long term in kanbans just as much as code.
- Keep it simple: or at least build up to complexity after showing good results from a simple version (hence I recommend starting with the standard columns).
- Start over: don't be afraid to iterate. If you try to (eliminate rework) you'll inadvertently maximise it. Instead make rework easier, permit yourself to start over (you want to minimise the time it takes to get into tackling the tasks on your kanban, known as the lead time).
Kanbans are practical knowledge: if they're not being productive they're not working.
This post is part of Supporting and structuring personal development and open source contributions with GitHub Projects, a series covering how I began using the GitHub Projects tool for tracking my personal development and shipping outside of work. Read on for the conclusion