It encourages learning and teams that deploy it get faster over time

This is a little older post from Eric Ries from June 2009, but with lots of good stuff in it.

Great bits:

The goal of continuous deployment is to help development teams drive waste out of their process by simultaneously reducing the batch size and increasing the tempo of their work. 

—-
 

One large source of waste in development is “double-checking.” 
…. how developers respond to this dilemma is determined by their incentives, which are driven by the culture of their team.

—-

Because feedback is slow in coming, the damage caused by a mistake is felt long after the decisions that caused the mistake were made, making learning difficult.

—-

Thanks to a phenomenon called the Fundamental Attribution Error in psychology, humans tend to become convinced that other people’s behavior is due to their fundamental attributes, like their character, ethics, or morality – even while we excuse our own actions as being influenced by circumstances.
So developers stuck in this world tend to think the other developers on their team are either, deep in their souls, plodding pedants or sloppy coders. Neither is true – they just have their incentives all messed up.

—-

You can’t change the underlying incentives of this situation by getting better at any one activity. Better release planning, estimating, architecting, or integrating will only mitigate the symptoms.

The only traditional technique for solving this problem is to add in massive queues in the forms of schedule padding, extra time for integration, code freezes and the like.

—-

Continuous deployment is another such technique, one with a unique power to change development team dynamics for the better.

—-

First, continuous deployment separates out two different definitions of the terms “release.” One is used by engineers to refer to the process of getting code fully integrated into production. Another is used by marketing to refer to what customers see. In traditional batch-and-queue development, these two concepts are linked. All customers will see the new software as soon as it’s deployed. 

I refer to these 2 terms as “Deployed” vs “Released”
See my whitepaper on “Use Scrum + Continuous Delivery to build the right thing” on scrum.org

“Released”: A business term that defines functionality being available to an end user”

“Deployed”: A technical concern that applies in the domain of the team and means the product is introduced in a chosen environment. Different environments have a different user community and might be: Production, Testing and Integration.

—-

In such circumstances, it’s much better for overall productivity for people to stop coding and start talking. Once they figure out how to coordinate their actions so that the work they are doing doesn’t have to be reworked, it’s productive to start coding again.

—-

Cowboys will start to learn what kinds of testing, preparation and checking really do let them work faster

—-

…the larger the batch size of their work, the harder it will be to get it integrated

—-

“code bouncing.”

Branching and merging hell

In my experience, just one or two episodes are enough to cure anyone of their desire to work in large batches.

—-

Because continuous deployment encourages learning, teams that practice it are able to get faster over time. That’s because each individual’s incentives are aligned with the goals of the whole team.

—-

…by reducing the overhead of doing a release, each engineer gets to work to their own release schedule.
That means, as soon as they are ready to deploy, they can.

So even if it’s midnight, if your feature is ready to go, you can check-in, deploy, and start talking to customers about it right away.
No extra approvals, meetings, or coordination required.
Just you, your code, and your customers. 
It’s pretty satisfying.

Full article
http://vator.tv/news/2009-06-16-why-continuous-deployment