Worked on a small group (2-3 people?) and .. 'agile-2-week-sprint-estimate-tickets-with-points' wasn't working well. This is 'startup/mvp' area, and we migrated to just a simpler task board. Owner moves tickets up and down in a "to do" queue, and someone (usually me) takes current 'to do' tickets, and does them and releases. The '2 week' time box wasn't really helping anything - we can 'release' multiple times per week.
For larger teams working on established product, there's more value to the '2-week-sprint-give-points-to-tickets' approach that's more popular. Worked in a group a few years ago like that, and... while there were some issues, they weren't specific to sprints or agile, more just growing pains of that company.
Do note Kanban can devolve into "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!". It happened to my team, and we had to ditch it because the stakeholders weren't onboard with no fixed cadence of deliveries.
Hum... Since the single main stated goal of kanban is to minimize WIP, it's safe to say that this is not kanban.
Of course, it won't stop bad managers from implementing it. But nothing will stop bad managers from implementing it anyway. Anything can devolve into that, trying to implement something different won't save you.
But that's the problem with agile.
Nobody can or wants to pin it down. When it fails, "you are not doing it properly". The stated goals are iterations, early feedback, people over processes... except when they aren't.
Do you mind defining this?
"Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)
Can the fixed cadence of deliveries be weekly or semi weekly status update of cards on the board? (Note: the view of the board should always be available to stakeholders, they may need to hold their breath for a week until a more in-depth status meeting of current cards on the board...)
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.
I need to reread the following books:
Kanban: Successful Evolutionary Change for Your Technology Business
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
The Goal: A Process of Ongoing Improvement.
The Deadline: A Novel About Project Management
From the outside, though, kanban looks more like "no methodology". If people who aren't on board look at both 2-week sprints and kanban, kanban looks a lot closer to "we can ask you to do whatever, whenever". It's wrong, of course, but in my experience they understand better that it's discouraged to insert new requirements in the middle of a sprint.
People will subvert whatever they want, though. Probably the biggest shortcoming with agile methodologies: "you are not doing it right" -- yeah, well, real people in the real world never do it right.
I am a big believer in "true agile", since "Agile" (note capital letter) has become heavily corrupted. "True agile" can really be summed up as "try some different things, keep what works for you". My team has a large number of independent projects, more than one per person. Because of that we tend to have one person working on a given project at a time, as that is a cheap way to avoid coordination overhead if you are able to get away with it.
What we found for "sprints" is that we couldn't plan anything with them, because the variance in how much time we were actually going to have to work on a project was too high. We might have the full two weeks to work on what we said we were going to work on. We might have a fire on another system that pulled that person away for literally 3/4ths of that "sprint". We might have an emergency feature request that could do the same thing. We found this variance to dominate the rest of our time planning, which resulted in our "sprint planning" being a bad joke. Nor could we just "git gud" at sprint planning, because the variance in the amount of time we had to spend on it was far, far too pathological.
I do not present this as evidence that "Sprints" are bad for everyone, only that there are cases where they really don't based on my experience as well. This has been my personal working mode for most of the last 10 years, and they've never worked for me. We've switched to a much more Kanban style of planning, which gives us the flexibility to deal with our issues without wrecking all our plans. I personally take the brunt of a lot of the highest frequency switching in our team, and my primary goal is that on a given day, I am working on one project, with a secondary goal of trying to keep it chunked up by week. That latter often fails, but I definitely try to avoid switching projects mid-day. (Which also fails, sometimes due to fires, but I've noticeably improved on this metric in the past couple of years.)
We've tried at least twice to switch to a more Sprint-y method of organization to better match the rest of the organization, but failed both times. I'm fine with the attempt, I'm just very glad we've also retained the flexibility to admit it was a failure, and that it isn't mandated from above that we must do the Sprint approach.
The vast bulk of teams in the rest of the organization I work in does have 3-7 person teams all working on one particular system, and while nobody ever escapes from the possibility of fires, they have a lower variance on the impact on that for all sorts of reasons. (Most notable being that 3/4ths of a week for one person out of 3-7 is a lower impact than 3/4ths of a week out of what was effectively zero people, which means it was actively drawing against what was nominally another project's time. That's a really big difference.) Sprints work much better for them. I'm sure they fail them sometimes but they generally seem to work for them.
I would argue that is more common sense than "True Agile." ;)
However, I think you hit the nail on the head with Sprints. I understand why organizations want estimates, planning, etc.. However, if I could predict the future, I would be working on Wall Street and not doing Agile. In my jaded experience, few things ever go to plan. I do think one should still plan, but I do not think plans should be immutable nor estimates turned into deadlines.
Sprints, to me, seem to be the antithesis of Agile. I find sprints turn Agile into a series of mini-Waterfalls.
