Hi! For what it’s worth I’ll share some of my own experiences and opinions of kanban and kanboard after having used it for at least 10 years at this point. My own uses are probably different from yours, so might not be relevant. But, in case they are or spark some ideas, here you go:
When transitioning from waterfall style planning with Gantt charts to more agile methods I recall being very confused about the relative lack of explicit dependency representation. However, before long I came to love it and kind of swung in the other direction (I’ll say a bit more below about how I view dependencies these days). The trouble you get into with writing down explicit dependencies, at least with certain kinds of work like software development, is that you almost always, eventually end up finding a dependency cycle that can’t obviously be resolved. “To do C we need to have finished B, but to do B we need to have finished A, but to even start A we need C done or at least underway.” It happens surprisingly often, and sometimes the cycle is invisible because it involves too many tasks. In my experience most of these cycles are false, though, in the sense that there’s a different way of planning to achieve the same goal that does not involve cycles in the tasks. I think when you change habits to planning in terms of fairly fine-grained tasks with minimal dependencies that have a clear “done” state, you start to see those different ways of planning, so it’s a worthy exercise to at least give it a try for awhile.
Kanboard does have a pretty rich set of relationships you can establish between cards, and you can add your own and add automatic actions too. I almost never use those features though, except for documentation/navigation purposes. I can’t speak for others, but personally I think it’s very illuminating to see how well you can plan without leaning on those features. Kanboard also allows for subtasks inside of a single card, but I don’t use that feature either. It’s another way of introducing a waterfall-style hard dependency between two tasks, but I think you can manage dependencies much more flexibly with cards. Using subtasks hamstring you by introducing a hard dependency but also by making adjusting the dependency structure harder (it’s trivial to drag cards around, harder to move subtasks from one card to another or to convert a subtask to a card). Kanban, and kanboard, gives you columns and swimlanes, but also the linear order of cards within a column, as ways of “implicitly” representing dependency structures and you can get very far using only those mechanisms.
One simple thing you can do to manage dependencies is:
-
Put cards that depend on others below them in a column (and potentially document that relationship)
-
When you’re going to do work, grab a card from the top of a column
-
When you’re moving a card from one column to another, always put it at the bottom of its new column (underneath the cards it depends on, which had to have been moved first)
-
Rearrange the order of the cards as you learn more about dependencies (make sure to update any relationships you have set in the cards if the relationship changes)
-
is something you need to do at planning time. 2. is a matter of discipline. 3. can be automated with automatic actions. 4. is something you need to do at review time minimally, and if you’re working in a team you should probably have consensus about such changes to avoid confusion and angst.
Another, I think more natural, way of managing dependencies that can work is using the columns to define a progression of tasks, and the cards as an instance of the task that needs to be completed. You then need to make sure you always move cards left-to-right when progression occurs. You can think of tasks as stages that an item passes through in this way of looking at things.
Anyway I know all that is not a direct answer to your question, but with luck it helps you see a little better whether you can map your use cases into (my way of using) kanban.
To run through how this might look using an example from your OP, you stated:
“Upgrade Server Foo” goal/task might be made up of the following dependencies or sub-tasks, e.g determine requirements, provision VM, install OS, install common apps, install main app, test, deploy
I see two ways to represent this in a kanban board, depending on the nature of these types of tasks. One would be to have a “Server Provisioning” board with columns corresponding to requirements gathering, VM provisioning, OS installation, app installation, main app, testing, and deployment. Each card would be a particular machine, or a particular group of machines perhaps, that is moving through this process through these stages. Here the dependencies are represented in the column names; as long as you follow the kanban discipline of moving cards left to right as a task progresses, you should be good. In essence you’re turning the representation inside out: instead of having a task like “install main app on vm-1”, you have a vm-1 card that can sit in the “install main app” column as that work is happening and be moved to the next column when it’s completed. I think this is the more natural way of applying kanban to something like this because you’re moving a “product” (the vm-1) through a series of processes (the columns) to get it to “done”, as opposed to managing “tasks” which is a more waterfall-y way of thinking.
If the tasks involved are not stable or common enough to be treated as stages, you could also make a set of cards per machine/group or machines. You could use a color or tag to coordinate all the cards for one particular machine or machine group. Then you’d enter cards like these, in this order, in a “Backlog” kind of column when you’re planning:
determine requirements
provision VM
install OS
install common apps
install main app
test
deploy
upgrade server foo
Whoever works on this grabs the top card, moves it to an “In progress” column, and starts working on it. When they’re done all work on that card, they slide the card to a “Done” column. You sometimes need a column or two in between “In progress” and “Done”, depending on your process (QA or testing and validation are common). The discipline you’ll need in this way of setting things up is that for a particular machine or machine group, no one grabs a card out of the backlog till all the cards above it are “Done”. That’d be easy to mess up, so relationships (for documentation purposes) would be helpful here and automated actions might provide a way of enforcing this kind of constraint. This feels like a more awkward way to use kanban, and that shows up in the extra mechanisms you need to use to make it work this way.
Anyway good luck! I’m happy to add more if it’s helpful.
