Let’s take a wild hypothesis that you want to improve your processes. The two things I’ve found the most useful for that, when your goal is opening gates and moving towards something more natural, are separation of concerns (SoC) and elevating the constraints.
Take your delivery process as an example, and suppose you want to have it more organic, i.e. with less artificial enhancers like a 2 week cycle. You could try to deliver to live every day, or several times a day.
Does it still feel weird and unsafe that you would be able to deploy live several times a day? Ask yourself why, because what you feel may either be real, or is just subjective apprehension coming from a lack of control. Either case is an issue and will require solving. In theory of constraints, Goldratt is advocating that at any given point of time, the general throughput of a given process at a given time* is caped by a very reduced number of constraints (usually one or two). Each improvement step may probably result in resistance coming from constraints you can act on.
You can’t QA everything on daily basis, let alone several times a day? Elevate: automate tests, and for those you can’t, determine a minimal set of tests that validates core functionality and gives you sufficient confidence in the stability. Then SoC (separation of concerns): focus on testing the potential side effects of the modification.
Any change on your application has wide side-effects that are too hard to control and therefore make the QA cycle too large? Elevate: make sure QA focuses on QA and devs are testing their code, then SoC: re-architecture your application to reduce the amount of regressions, so that modifying a module has only local impacts.
Deploying takes too much time to do it several times a day? Elevate: automate it.
Ever-moving user interfaces are not good for usability? SoC: deploy but hide modifications using feature flags. Elevate: why is it bad in the first place? Isn’t there a way to make it consistent and empower the user in the changing UI process by giving them more control?
Of course it’s only an example on the delivery process. But the point is: what is preventing you from moving forward needs to be solved, not worked around. Working around is usually procrastination or short term patching. Fixing is usually a one-time investment on the long-term.
There are cases where elevating the constraint is not justified by business, or the cost is simply too high. But there never is a case where the question is not worth asking: what’s preventing us from going to the next step, isn’t it actually preventing us to progress at all, and how can we kill it?
* Emphasis on the “At a given time”, because of course when you elevate these constraints, they are not constraints anymore. But a couple other constraints will still be limiting your throughput. It’s an iterative process.
** These are actual questions that we asked ourselves while implementing some form of lean/kanban at my job, and their actual response in our context.