The development team operates using an agile methodology that divides work into units called sprints. These sprints last about two weeks, though in practical terms they're about nine working days when you factor in some of the activities that surround the planning and retrospective process. We are constantly prioritizing our backlog of work, and then the product owner, development team and other stakeholders decide what work to queue up for the next sprint. The sprint ends at the end of the day Wednesday, and then following a stabilization period for QA work, we deploy the new code the following Monday.

So why two weeks? The first reason is that we're never more than two weeks away from correcting a problem. Another reason is that it helps us avoid "big bang" moments with a lot of change and the inherent risks associated with a lot of change. The sprint allows us to move a discreet amount of work to customers in a predictable way.

Our criteria for deploying an out-of-band release is very high. There must be a bug or problem that quite literally stops business or causes monetary disruption. These instances are very rare.

Why is our criteria so high? The biggest reason is that deploying code is an inherently risky action, even with high levels of automation and testing. We mitigate the risk by being thorough in our QA process, without rushing it. Another consideration is that we often have multiple, interdependent work items in flight, so the code is quite literally half-baked and can't be used until the items are completed.