You don't need Scrum, you just need to do Kanban right (2022)

Sounds like you have a very poorly run and dysfunctional team. When applied correctly, good project management ends up better for everyone.

I am probably missing something but is kanban even the correct metaphor for creative work(like software development).

Kanban is a back pressure mechanism that can get your factory logistics system running smoothly. However the logistics of creative work is very different than the logistics of assembly work. There are almost no parts needed, why is a backpressure system for part delivery even useful?

I’m not a huge scrum defender - I’ve seen it done right and wrong. Same with Kanban. The only real problems I have with Kanban is that without those annoying team planning/documentation meetings, work will get duplicated, done hastily, done with no discussion or thought toward testing, architecture, maintainability. And that’s not exclusively true of Kanban. But I feel like the lack of organization can turn it from less of a “flow state agile” and more into an insane command economy/death march/spaghetti factory. I usually feel Scrum teams are happier, more close-knit and aware of the impacts of teammates work, and more excited about “doing agile right” than in Kanban - which often feels very siloed and “heads down”. Different strokes, I guess.

They're prioritized tasks. They're pulled through. Simplicity is the structure.

> This demand for estimations leads to unproductive and unnecessary estimation meetings. These meetings are unproductive because they cause developers to spend time debating whether something is worth two or three story points instead of actually writing code. They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter.

Only if all tasks are of equal priority, which is rare. Otherwise you need some (very basic) cost estimation in order to prioritize.

> Retrospective sessions are also fundamental for a team to continuously improve the way it works. The problem with these sessions in Scrum is that they either happen too early or late. Although it’s good for teams to discuss their practices and look for ways to improve them, it may not be necessary to hold a retrospective session if everything is going fantastically well. Conversely, it may be harmful to wait for two or more weeks to discuss systemic problems impacting the current pieces of work or the overall goal the team is working towards.

> In Kanban, there’s nothing preventing teams from scheduling regular meetings. Yet, teams have the flexibility to schedule meetings whenever they’re necessary.

But unfortunately this means they also have the flexibility to not hold a meeting when it's necessary.

I don't think this article is exactly wrong - Scrum is to a certain extent a crutch, just as any process is to a certain extent a crutch - but I think it overestimates the average manager/team. In my experience teams that pick Kanban over Scrum tend to have issues with stalled, overly-large, and poorly-prioritised tasks (e.g. an undesirable task can sit indefinitely in the "ready for work" column which is usually not what you want), too little process refinement (in particular, retrospectives end up being rare) and take too long to recognise issues.

Scrum is prescriptive and restrictive, but it's like that because it works. After all, if your team was perfect you wouldn't need Kanban either. Just do the right thing and don't do the wrong thing bro.