Last year I wrote about the need to prioritise in choosing what to develop in a personal kanban. This means to decide on your mission statement as a solo developer, or organisational goals in a team.
To state the obvious: prioritisation is futile without coordination, else ideas you are aware are important will leak out of the pipeline. Priority isn't a property that a project can intrinsically possess, it's an ongoing, active process.
Like any process, kanbans can fail. Projects can suffer from defects, critical ones even, if workflows are ambiguous or poorly structured. These are design flaws, not from misuse so much as lack of forethought.
This is why I've decided to create an SOP (Standard Operating Procedure) for GitHub Projects: not merely to demo how I use it, but more importantly to express my view on design aspects for success, and the minimum level of item detail and organisational structure to avoid these pitfalls.