Some things are hard to change. A policy that seems to haunt me is that you must stabilize (or harden) a release candidate for a certain period of time (for instance in the staging environment), before you can deploy it in production.
Last week I tweeted:
If no work is done on a system in staging environment, it doesn’t have to be there for a week. Result is only prolonged feedback loop. #lean
One reason for establishing this kind of policy might be that it’s related to a (predefined) release schedule. The system simply has to stay there until it’s time for the next release. The problem, from a lean perspective, is that most of the time stabilizing is waiting (or idle) time. You build inventory.
Ideally you should try to minimize the waiting time by deploying more frequently. If you don’t know where to start, you can read up on continuous delivery, but you can make thing better simply by moving the value adding activities earlier. This makes sense because you shorten the feedback loop.
In other words:
Instead, define the value added activities that must be done in the staging environment and make sure they happen as soon as possible.
Disclaimer: This blogpost was originally published on a different platform. Formatting may be incorrect, links may be out of date.
Jørn Hunskaar 