Which is another flavor of Agile which is what everyone is always complaining about. I'd take some form of Kanban any day over doing rigid Scrum by the book. Kanban needs a lot very similar meetings though. You still need to fill the backlog, discuss the tickets. If you were to do Kanban by the book as described by the Agile Alliance, you'd still do standups, retro under a different name etc.

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?

How do you refine features? How do you discuss team improvement measures? How does prioritization happen if you're working on a product?

The answer might be simple for small teams, but a lot more complex for larger teams, where the result might look eerily close to Scrum. One difference would be that meetings will take place infrequently and only "as needed", where I wouldn't trust most teams to recognize their needs.

> How do you refine features?

I'm really curious about this question, are you thinking that not having Scrum makes it's harder to refine features?

I'm trying to understand what assumptions you are making, because I've never worked in a Scrum environment, but have always refined features as part of the natural flow.

> have always refined features as part of the natural flow.

"natural" as in "law of nature"? Or is it just a process which crystallized in the course of your career as something which makes sense to do?

Scrum, and other methodologies are mostly a collection of such processes which proved to be useful, are somewhat standardized for learning and communication.

One can reinvent many of the Scrum processes independently, but I kinda don't see the point. Just like I'd rather use a finished library / framework rather than try to hack together my own.

No, but I believe that whatever you're doing resembles what is done in scrum. Gather information, discuss with your colleagues, create a plan. Scrum enforces that colleagues talk to each other, which I learned is not always the case.