There are many reasons why organisations go about experimenting Kanban. Often, it is the Operation and Service Delivery teams who would like to be more Agile but find Scrum a bit too unsuitable to their taste due to ever changing priorities. One cannot ignore the difficulty in planning for a sprint when you have no idea what you might be working on tomorrow, let alone a week later. Even though retrospectives and standups are useful practices that can be applied by almost every team in any business, planning and sprint review type of activities from Scrum world may not be straightforward to follow by all.
Another reason of trialling Kanban is to be able to identify the bottlenecks in the flow and pay more attention to those areas to improve delivery speed and quality. Once the Kanban WIP limits are in place, the areas that we struggle as a team will be visible quite quickly, mostly within few weeks. Moreover, we have to focus on those problems and fix them as a team immediately otherwise we will not be able to pick new tasks. Having the sword of Damocles hanging over our head, the team realises the importance of collaboration better since the success and the failure are both measured as a team rather than as individuals. In software development teams, that would often means giving a sincere hand to QA and work together more in order to deliver a story or a task. In an operational team, it could cause the information or know-how to be distributed more generously between team members by additional training or pairing so that the team as a whole can deliver more.
Working in Agile world quite long years, I had a chance of using Kanban across various organisations. Relying on personal experience, I would say it is a crucial part of Agile practices even though not necessarily suitable to every single team. I think the development teams with a very good self discipline, the ones that digested Scrum principles so much so that they don’t need them anymore, can easily practice Kanban with if they have the means to be able release quickly. I personally don’t agree with the strong assertions that you should stop estimations in Kanban style of work, or that you don’t need retrospectives at all. I think you can still use them as and when required depending on the type of the business being conducted. The main benefit I can see is that it brings out a whole new scale of agility to the game, but only for the teams that mastered the Scrum and Agile principles.
The analogy I make is the Guitar vs. Oud. Guitar is traditionally a fretted instrument which gives the player a possibility to learn relatively quickly and still produce a nice music within its limits. Oud, on the other hand, is fretless meaning that the player needs to show a bit more effort and discipline to master it. However, once you master it, the possibilities it provide are incomparable. There is an Anatolian musician named Erkan Ogur, who makes a great music with a lot of different instruments, choose to call Oud as “million fretted” instrument rather than “fretless”.