I've been asking a lot of people who are software developers if their teams use Kanban boards to track progress. However, this seems to be a polarizing question as some people really hate Kanbans or love them with very few people being ambivalent about them.
I'm curious how does the Indiehackers feel about Kanbans and do you use them for something other than software development?
I am a Restyaboard user. With the right Kanban board software, you can focus on your priorities, keep your team in the loop about what’s current and what’s coming up, and you can control a steady flow of work, especially in output-heavy environments like production, agencies, support, and maintenance.
I use Trello for everything - digital services for clients, SaaS development & marketing as well as private tasks. 15+ active boards. I can't imagine how could I manage without it.
No. We hated them enough to build Uclusion to address the shortcomings of Kanban for software devs.
There's more, but in general it's not the greatest fit for anything that requires synchronization, status, and context to all work together.
Anyways, long rant, but it boils down to Kanban's great for a factory floor of fixed tasks, but leaves you hanging for everything else.
While I can empathize with your point, I have to disagree with your closing statement that "Kanban's are great for a factory floor of fixed tasks but leaves you hanging for everything else".
At least for relatively small teams, I'm a big fan of the Kanban board particularly for projects with rapidly changing requirements and to dos. I think the mistake most people make is obsessing over detailing every task very thoroughly (thus increasing the cost of adding/removing things to the board), or stuffing too much information into a single board (thus decreasing the visibility of project at hand). I talk a bit about this in my forthcoming article about our migration from Azure Devops to Github.
We use a 'global' board to view the overall status of our current projects, then one board per significant project. To elaborate a bit, we may denote 'Sprint 6 for Product X' in the global board, and then detail the various tasks within that sprint within the board for 'Product X'.
Yes, I think you are correct that you shouldn't put too much detail, but when you're at that point the card and column isn't really helping you. You'd be better off not paying the overhead of the Kanban system and just maintaining a shared requirements doc. The "high level" stuff isn't even being executed anyways, since it's not in sufficient detail to do so.
We tried out the "global" board to sub board approach too, but that breaks down hard when you have tasks running in parallel in different sub boards. You lose the majority of the benefit Kanban's supposed to give, which is fast access to status. When we were making Uclusion we had that problem too, until we got hit by a clue bat by one of our prospects, and made the homepage show you tasks across all sub boards in separate swim lanes.
This has been fun talking with you, can you send me your article when it comes out? It's [email protected]
Hey there - just following up with the article I mentioned :) Hope you have a great weekend. https://www.prettyneat.io/github-vs-azure-devops/
Thanks, I just read it, and I totally agree on the complexity front. It's why I'm not to into integrations and any app that requires more than 15 minutes to set up for your team. It's also why we have a total of 2 knobs on Uclusion, and everything else is completely automated or you only get the default. It always amazes me how much harder it is to REMOVE a knob or a switch, than it is to add it.
Kanban works very well if you're working in a team. It's easy to define actions and delegate to team members.