Be yourself, innovate, and have fun releasing more frequently. These stories show that you don't need to follow a formula.
This section contains stories about teams releasing frequently. All of the stories are different, and they are in different formats. If you do large scale software development or build a product, I recommend that you read all of these stories and consider the various approaches. If you do smaller projects for clients, you can skip to "Working with Clients" and get some useful hints.
You may eventually get sucked in by some common trends and themes. Here are a few things that came up frequently.
Many virtual servers. Continuous delivery takes a LOT of servers. Don't fight it. Automation is good. Servers are cheaper than people.
Distributed teams. Your teams will spread out and manage their own time. Help them become happy.
Programmer responsibility. Programmers incrementally take control of the release schedule, testing, and operations.
Team restructuring. We found that teams took complete responsibility for one or more front-end services, plus any related back-end services. QA professionals were blended with programming teams. Some organizations kept scrum-style multifunctional teams, but run by programming tech leads, and some went directly to a core of programmers, plus other functions (design, db, test, ops) as consultants.
Inadequate use of data. We have a lot of data about how people use software, lying around in logs, and even in reports and dashboards, but we aren't using it. Only the best organizations are using all of their data to figure out what features and changes have high impact, and invest in those.
Service architecture and MAXOS organization. As I collected these stories, I came to an unexpected discovery. The best organizations have traveled on different journeys, with different vocabulary, and different tools, but they have arrived at a similar technique, which I call Matrix of Services or MAXOS. They are dividing their apps and infrastructure into many Web services. They run continuous delivery for each service. They use automated testing to continuously integrate the most recent version of each service. This technique ingeniously replaces the very difficult job of project management, dependency planning, and scrum of scrums with continuous integration - that is, with a machine. I've made notes about this technique in the stories about Google, HubSpot, and Edmunds.