On LinkedIn, J. B. Rainsberger recently posted something that really resonates with me.

Delivering frequently doesn’t mean “Always Be Shipping New Features”. It means practising delivery until you can do it in your sleep.

I totally agree with this, although I might expand it a bit. (Getting a good idea to be both complete and succinct is near impossible.)

To me there’s two parts to this, and I only point it out because I have had suffering from both sides.

The first is figuring out your process to deliver, and getting good at that. I’ll admit that I am not very good at this, and the practice he mentions is something I need to get better at.

The second is helping to fix the actual process. Sometimes, and I’ll assert confidently (and possibly incorrectly) that the majority of “delay pain” is due to a suboptimal process. In many places the devs have zero control over that other than suggestions, and then only if the generally overworked team that handles that can actually get the time to implement them.

So to the extent that you can actually influence or help implement the actual deploy process, do so. The goal here should be (paraphrased from Dave Farley):

The only 2 things a developer should have to do to deploy software is a) pick the version to deploy and the environment to deploy to, and b) click the “deploy” button.