I don’t believe in sprints

Yep.

Also I've never seen a Kanban operation deliver everything to Production as soon as it hits a "Done" column and there's no reason not to "time gate" (once every fortnite, just like Sprints are supposed to be, for instance) a Production column "pull".

I think that's easily missed in Kanban versus Scrum discussions: every Kanban column is supposed to be "pull" rather than "push". Production "pulls" finished UAT stories when it is ready (which maybe is a biweekly schedule that keeps ops happy and gives marketing time to prepare materials, etc). (I also think that's why a lot of micro-managers dislike Kanban versus Scrum, because they want to "push" everything and dislike people making their own "pull" judgments based on their current bandwidth and ability.) The failure case of "Production pulls finished work" is that Production sometimes wants to cherry-pick finished work ("I want these three but not this fourth one") after they've been already merged for UAT testing. I've not seen a good Kanban software that visualizes that "state change" of stacking cards together as they become bundled together/releasable units.

> The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints?

I don't know, your problem statement doesn't allow me to formulate an answer. I suspect whatever the project, it can be split into a series of more manageable chunks.

I could care less if a team is ‘agile’ but I do care if it has practices that are effective for the group and the work that it does. If anything a good process is not about using good methods but avoiding the bad ones that predictably blindside people every time.

For instance, I think the kanban concept is more basic than estimation. That is, teams that keep starting new work without finishing the old work are working very hard but get very little ‘done’. Thus you have some limit on how many tickets can be open. I know a very well run cafe where that’s the main management practice they use, only taking orders when they are running low on work in progress.

My beef with estimation is that the model that ‘task A has N subtasks and you can estimate the individual subtasks and add them up’ (which works well in a certain sense) is often less correct with the model that ‘the developer sends a work unit to the tester which may or not be sent back to the developer’… in which case the most important factor for how long it takes to do work is how many times you send it off to the tester.

Sometimes I dream about working with a ‘tester’ in a much more closely coupled way than I do. I always have to ‘test’ something myself to convince myself it works to avoid the embarrassment of sending something to the tester that is 100% busted. I frequently spend a huge amount of time setting up tools and environments for testing. That includes the traditional unit testing (which runs quickly) but also processes like building a full text search index for a system with a few million records, testing to see that a machine learning model builds automatically and works properly, that a full text search engine gives relevant results, or spending four hours building a database so I can run interactive queries against it.

If somebody was helping out on that kind of stuff and could test stuff I do with a turnaround of minutes instead of ‘fill out a lot of paperwork and wait 2 days to 2 weeks’ I’d spend more time thinking and coding. (W/ the caveat that thinking about testing can lead to a better design more often than it leads to Test Driven Design Deformation.)

Hum, no. If you go calling some infinite WIP generating process by the name that has as the one most important principle "no matter what you do, keep WIP down", it's you that are bastardizing the language.

No, you can absolutely achieve that goal using other processes. However, in my experience I've found sprints to be the way that works best for the teams I've been on and those I've lead. But it all depends on the team and how they structure the sprints.

In the case of the teams I've been on and lead, the sprint is structured with a planning meeting at the beginning of the sprint in which everyone goes over each story. Stories with enough complexity to warrant it have an execution plan attached (written during a SPIKE in a previous sprint) that allow the whole team to collaborate on the execution - everyone can go over the plan together, agree on the approach, poke any holes in it, etc. And this gives everyone a much clearer picture of what's being worked on.

In my experience with Kanban, it's much easier for developers to lose track of the work of the whole team. They focus on their current task, and the task they plan to pick up next. Being able to see the work on the board isn't the same thing as actually knowing and understanding it. Sprint planning lends itself much more to that.

That isn't to say you couldn't run an equally collaborative Kanban process with some work. My experience was just that it was much harder to achieve that level of collaboration with Kanban. That's through several iterations on different teams. Not impossible, just harder. And when there's a ton going on and you're going fast, you generally want your process to make it easier to work the way you want to work. IE. You don't want to have to work extra hard to make your process collaborative, you want your process to make it so that it's hard not to be collaborative.

But again, this was just my experience on a few teams and what works for those teams.