In my experience people complain about strict processes that books or consultants say must be followed. I've rarely heard someone complain about the content of the agile manifesto. So start with what you've got, and iteratively keep what works and chuck what doesn't, until you have a process that works.
I'll add that kanban means much less time filling a backlog, to the point that an individual can own that, and you're eliminating that meeting.
> I'll add that kanban means much less time filling a backlog, to the point that an individual can own that, and you're eliminating that meeting.
I've only ever been on projects where the backlog was filled by a PM and or lead engineer and then reviewed collectively and maybe some amount of re-shuffling would take place. Are you saying you've been in meetings where the backlog started empty and it was populate with the entire team in the room?
I've never seen an empty backlog, but I've been in meetings the purpose of which is for an entire team to rubberstamp the order of the backlog. This is "grooming" or more recently "backlog refinement". You don't need to do this in kanban.
Don't you need to go over newly added tickets and ensure the tickets are clear, order makes sense, etc? Whenever we've skipped this some issues would emerge when tickets get picked up later. Depending on the project domain and if a PM or engineering lead wrote the tickets the issues would be either more about technical issues or misunderstanding of business requirements.
> I've never seen an empty backlog
How about a backlog with stuff near the top that's no longer relevant or has drastically dropped in importance?
Tickets are often written imperfectly but that doesn't necessitate a standing meeting for the whole team imo. Make your pm and em hash them out, make the most informed engineer write the ticket, but don't make everybody watch.
If the top of your backlog is uselessly stale, you're spending too much time writing tickets in the distant past and not enough recently (or maybe congrats on your velocity?). A ticket that's so old it needs to be overhauled to be worked on was written prematurely. This is one of the things kanban is good at.
Edit to add: a team that's heavily reliant on a PM might not be a great fit for kanban? It's not for all teams, and is a natural fit for some
What you are describing is entirely reasonable, but again still a lightweight Agile process. The thing that I don't understand is what the people want who keep complaining about all Agile, not just (rigid) Scrum in particular. I've worked with XP, Scrum, Kanban and versions of those adjusted to particular teams and companies. If someone doesn't want any Agile and doesn't want Waterfall, wtf do they want?
I'll add that kanban means much less time filling a backlog, to the point that an individual can own that, and you're eliminating that meeting.