How strictly should we stick to the rules of Scrum and Kanban?
There are generally two schools of thought on that matter, and I, personally, lean a bit more towards one over the other. The question is a good one, because very often, agile transformations fail because some of the rules are neglected - it's like trying to buy a sports car with the engine of a Fiat Punto, and then blaming the car (and not your own decision making) for being slow.
Arguments for strict observation of the rules
The first and foremost argument for strict observation is: The rules are there for a reason. No one has put them in just because they needed to get to a specific number of rules, or just for fun. Therefore, we can assume that a rule which we do not understand might solve a problem we didn't have yet, or we don't realize we are having.
Since we only see the rule, and don't fully understand the problem it tries to solve, we are also not able to connect the problems we are having to the missing rules. Simply put, not obeying one of the rules could create a problem, and if it does, we wouldn't even be able to understand that this problem could be solved by the rule we skipped!
The Japanese concept of Shuhari suggests that at the entry level, we should meet the rules with reverence and follow them to the letter, acknowledging that we see past the rules and discover that they have been laid out by smart people who were distilling their own respective decades of experience into these rules. At later stages, however, it's possible to bend, break and even abandon the rules.
Arguments against strict observation of the rules
On the flip side, the typical argument against strict observation of the rules is the desire to keep things simple. It's generally easier to adopt only parts of a framework or rule book, and it doesn't make sense to adopt rules just for the sake of following the rules - if we can't see the problems that are supposed to get solved, there is really not much sense in bothering to implement the rules.
The middle ground
I generally lean towards a results-focussed environment. Does your team deliver satisfying software at a satisfying pace with satisfying quality? Then your process most likely doesn't need any fixing. Break the rules all you want! If, however, you are unhappy with the outcome of your team, investigate the parts where you are not following the rules first. Check if the problem you are seeing might be solved by what is already in the respective toolboxes of Scrum or Kanban before trying anything else - it's very likely that there is something in there which helps you making sense of your current situation. Only after you have exhausted all your options there you should try something else.