Principles are more important than the actual processes. They define core ideas around which processes should be built. The key to consistency is to rarely change principles while constantly improving and modifying the processes with a goal to implement those principles in a better way.
Let’s take software development lifecycle as an example. A rarely changing process would most certainly cause a major slowdown in an actively changing environment, such as a startup. A well tested two weeks long sprints and ceremonies around them may work great for a team in a pre-release stage. Then suddenly after launch, they may find themselves in a different environment with a large amount of incoming change requests that cannot really wait for weeks of planning and coding. They decide to adopt a Kanban approach as they see it as a better process for this time given the new mode of working.
While the process has changed for the team, the core principle of agile development “responding to change over following a plan” is still maintained and their work style is consistently agile. However, if at some point they decide to stop everything and plan every detail of their work for the next six months and then follow that plan no matter what, this will be a significant change in their principles and will lead to a major change in the organisation overall.
Keeping principle fixed and processes flexible helps teams to self-organise and constantly shape the process towards the most efficient way of working.