I have worked on several Scrum teams and a couple of Kanban teams throughout my time as a developer. Most of the times I have worked with Kanban it has been with elements from Scrum such as Retrospective and Daily stand up (which I find to be good practices when done properly). In this post I will go into some of the reasons I have experienced that lead teams to practice Kanban instead of Scrum.
The teams I have been on that moved away from Scrum and into Kanban mostly did so due to continuous failed sprints. The teams had a hard time committing to their goals either due to organisational limitations or an unpredictable environment. This makes it hard to practice Scrum as Scrum focuses on having as little change as possible within a sprint and committing to finishing all the stories or tasks in the sprint.
Organisational limitations
One of the reasons teams fail at Scrum are organisational limitations. One of the limitations can be that you cannot get a dedicated product owner who stays with the team and the product. Rather than having an organisation that focuses on products it focuses on projects. This means that the products and the owner of these are not static on the team but rather change hands or are handed over to maintenance teams when they are done. The members of the team are also at risk, if the members of the team are changed often it can be hard to calculate your velocity and thereby commit to the sprint backlog. With Kanban there is no velocity that takes a hit when the team is changed, but do not confuse this with no change in productivity. When knowledgeable people leave a team or the team gets a new product in its portfolio the performance can tank - no matter which agile approach you take.
Outside dependencies
Organisational limitations can also come from outside the team. Yes in the ideal world the team can create a feature, test it, present it and if approved move it to production. But sometimes a team relies on a feature developed by another team and this dependency can put your sprint at risk. You could say that your definition of ready dictates that the feature should be ready before you can commit to a task that depends on it. However you may discover during your sprint that the feature is lacking, you cannot get support for it or it is not working as expected. You may have to fail your sprint and plan again if you really need this feature.
Another thing I have seen is that the people who are to approve or test a feature within a sprint are unavailable. Some monolithic systems are so cumbersome to test that it takes days or weeks to test everything manually for users. This makes it hard to deliver within a sprint, a workaround I have seen for this is the team changes the Definition of Done to software being in "ready for test" instead of "Working in production", however having software in "ready for test" delivers no value to our users or clients. With sprints it can be hard to calculate how much goes into the next sprint when everything is stuck in the "ready for test" column, waiting for approval or otherwise is half-finished from the previous sprint.
Without sprints (Kanban) there is no "rush" to finish it within the current sprint, there is no pain of failed sprints, but you still want to get everything across the board ASAP (this does not change between the two methods). However continuously failing sprints is painful, it also makes it harder to get a good flow in Scrum when a lot of half finished tasks are moved to the next sprint in every planning.
An unpredictable environment
Another major reason that teams move away from Scrum is that they have a hard time locking their sprints. Most teams I have seen have had 14 days sprints where they try to lock the sprint backlog and change as little as possible. For some teams this works fine, they are able to finish what is within the sprint with no to little interference from the outside world, other teams are struggling with production issues, sudden changes of priorities or other disruptions to their sprint.
It could be that you often have production issues and that is hard to live up to what you have planned and committed to. If you work with software with high levels of technical debt and surprises around every corner, it may be hard to estimate tasks meaningfully (and thereby plan a sprint). As Kanban does not try to lock the sprint backlog it is more adaptable to sudden change in priorities.
Too much overhead
One of the reasons I often hear for leaving Scrum behind is the amount of "overhead". Scrum has many ceremonies: daily stand up, retrospective, review, planning and refinement. These take place at least once within each sprint with daily stand up being every day. However I would argue that I have found these ceremonies except for "planning" on every team I have been on regardless of the agile method. However they have not always been in cycles of sprints, instead they have been held as they were needed and with who was needed.
Due to Scrum repeating these meetings to be held for every sprint and requiring the whole team to be present, it takes up a lot of space in the calendar. This may seem intimidating to some developers and they start asking for alternatives such as Kanban (as they get to cherry pick their ceremonies). Even under Kanban you still need to refine, review (demo) and improve your process (retrospective), but the cycle of which you do this is independent of sprints. I have never been on a team with no daily stand up, except for once on a two-man team where we practically pair programmed most of our days away. The same ceremonies often appear in both Kanban and Scrum but the frequency is different.
When I write that I did not have "planning" on every team I have been on, I mean that in relation to sprints. All teams (mostly done by the Product Owner) forecasts and try to look ahead and plan for the future. But that does not mean they commit to a sprint of a fixed length. They do not have a planning session but rather a prioritised backlog that the team could pick up items from.
I think it is exaggerated when it is stated that there is too much overhead in Scrum. The sprint length can be adjusted to be longer as the team gets used to the process, this can reduce the amount of time spent on planning, retrospective and review. A lot of the hate for Scrum ceremonies come from bad meeting etiquette: not starting on time, not showing up, having no schedule or going overtime.
Planning especially starts to feel like overhead if it drags out. But calculating velocity, putting items into the sprint backlog and starting the sprint should take little to no time if everyone is prepared. However if the product owner is not clear on the prioritisation or some items are missing refinement, this meeting can feel like forever, especially when you just want to get started with the sprint. This is an example of Scrum done wrong and can cause a lot of frustration.
Wrapping it up
Organisational limitations and unpredictable environments are the key reasons I see teams move to Kanban or Scrumban. Scrum is a great method for putting some light on what does not work and dealing with it. During your retrospectives you may agree that the team should be more cross-functional and bring in some quality assurance resources for the testing or you may also find ways to reduce time spent on maintenance. However when these problems have been discussed for the last ten retrospectives and nothing happens you may want to consider moving away from having commitment or sprints and into Scrumban.
Kanban is often less painful as there are no sprints and less ceremonies. Due to this it adapts better in environments where teams are in less control. There is no reason to keep committing to sprints when you do not have the necessary resources or the right circumstances to live up to it. These are the reasons why I see Scrum teams move to Kanban or Scrumban. This does not only give the team freedom, but also the product owner to change priorities - and yes it costs to change priorities but it is better than working on the wrong items or making commitments that never work.
Choose the methodology that makes the most sense in your given context.