Kanban and Scrum are completely different concepts used for managing resources to solve completely different circumstances.
Kanban is a ticketing system to ensure a pool of resources can deploy proper and sufficient resources to a task and for the pool to refuse request for service until sufficient amount of resources are free to be deployed.
For a facilities department, let us say it maintains 20 kanban tickets (either physical card or computer registered tokens, doesn't matter).
A service request to fix a pipe, seen as requesting for 3 tickets, is serviced and so now the facilities resource pool has only 17 tickets left. As the day went by, more services are requested or deployed by schedule and a queue of service requests forms because the department has deployed all its tickets. Let us say that at the current level, 19 tickets have been deployed, and a next request is in the queue which requires 2 tickets. But somewhere down the line, are a few requests that require only one ticket. So should we let the queue to be blocked or let the tiny one ticket jobs to be done? Because what if 2 tickets return later to construct a complete three-ticket resource? Therefore we need to have scheduling capability to make such decisions to know when tickets are returning.
However scrum is not a resource-to-service management framework. It is an agile project management framework that does not have resource capacity tracking. It depends on the service providers who are "bacon" members of the scrum to judge how long they need to accomplish a task.
Scrumming facilitates fast turn-around by breaking a project up into small fluid micro projects. It used to be that the waterfall method would stretch a project to months or years before being released for use. However, scrum and agile project management frameworks shows evidence of having originated from rebellion against the old school waterfall masters who used to call these short-turnaround strategies as lazy, incomplete, constantly shifting targets, unable to nail down any real needs.
But that is exactly what the real world is - lazy, incomplete, constantly shifting targets, unable to nail down any real needs. By the time a traditional waterfall project had completed it normally would have become misaligned with the users as the requirements have changed significantly. Comparing scrum/agile to waterfall is like comparing reduced-instruction-set-computers with complex-instruction-set-computers. if we reduce the granularity of a project's components, we have a lower chance of resource duplication. Due to the small granularity, the project's microtargets and consequently the project on the whole is able to move with the moving targets.
Agile project management strategies like scrumming encourages an attitude towards product release which is do it quick, precise and do it often. It has a great advantage because for example, if a project is to accomplish a product with 10 features, why not create a product with just one feature and release it and then release a new feature every week. By doing so, both consumer and supplier can make immediate adjustments to their misconceptions.
Traditional waterfall presumes the consumer's specs are perfect and provides some mid-term reviews but never a product to the consumer. By the time the product is released, both consumers and suppliers finally realised too many presumptons have gone wrong and were not rectifiable because they were not brought to light. As far as the supplier is concerned, they have fulfilled their end of the contract and the consumer should pay up before attending their own (project) funeral.
However, agile project management requires commitment from both the consumer and supplier. The consumer must want and willing to use a frequently changing product. If not, agile management is pretty much handicapped. One way is for the suppliers to have its own team of pseudo-consumers who must be completely in-tune with the attitudes and practices of the actual consumers. If such internal pseudo-consumers(normally those presumptuous sales and customer service engineers/scientists) also refuse to participate, agile techniques is doomed for failure because, what is the point of quick turnaround if there is nobody to provide feedback? I have seen scrum fail because customer service refuse to participate.
Also, scrum tends to fail when members treat the daily scrumming sessions as project and excuse reporting rather than serving the actual purpose of being a quick, convenient and physical bulletin board of exchange and synchronisation.
Perhaps, you could merge kanban with scrum so that scrum has a definite way of producing time-lines because currently it depends on a resource owner to wet his/her finger and stick it in the air to come up with a schedule. But in my opinion it is probably not workable because kanban is used to manage a stable and defined service environment whereas scrum is used to manage a constantly changing development rather than service environment.
As the level of expertise matures, the facilities department may find itself with a group people who could perform tasks faster so that a job that used to require 3 tickets now requires only 2. Maybe somebody quit and an inexperienced hand is hired as replacement. There is no such provision in scrum.