I actually do agree with you that kanban is very flexible - and I have used plenty of additional swimlanes - for my original example we tried using "concepting" stage, multiple iterations, "mix" swimlanes for individual sound effects. These aren't "outcome" swimlanes, because I found that tracking an outcome becomes overly complex tracking subdependencies of the tasks of that outcome. At that point, Scrum becomes better at handling that complexity.
Which is why I always come back to "the best tool is the simplest that meets your need" - starting at Kanban is good, then you can add complexity. If that complexity starts to "outgrow" kanban (though it's a bit like comparing apples and oranges - it's not like scrum is just a more complex kanban, so I'm oversimplifying here) then you want to consider switching to another technique.
It's great that kanban has worked for all your projects and you haven't needed to use scrum!
Thank you for explaining, and it’s great that Scrum is working for you and your team! However, I have to admit I still don’t get it. How is Scrum better at handling outcomes? Are you talking about the sprint goal rallying all the team around a specific outcome, within a specific time frame? I gotta admit I am very suspicious of this way of working because it gets unsustainable pretty quickly, but I would like you to elaborate if you have the time.
Which is why I always come back to "the best tool is the simplest that meets your need" - starting at Kanban is good, then you can add complexity. If that complexity starts to "outgrow" kanban (though it's a bit like comparing apples and oranges - it's not like scrum is just a more complex kanban, so I'm oversimplifying here) then you want to consider switching to another technique.
It's great that kanban has worked for all your projects and you haven't needed to use scrum!