Don’t change your process right after you kick off the next release.
Don’t change your process mid-release.
Doing either of the above actions is guaranteed to throw a wrench into your gears and slow your team down when you need them focused on what they are doing and not how they are doing it.
Assuming you’re still delivering, gather feedback and if small tweak it in the next sprint, if it’s big, save it for the end of the release. If it’s a result of a bigger change you are doing, do it before your next release, but give your team time to soak into it (hotfixes, patches) before doing the next major thing.
And if you don’t know why you are changing things, don’t change them.
