The long-awaited software revolution is upon us. Small startups deliver "minimum viable products" in a few weeks and then evolve them. Huge phone companies win billions if they can beat the competition to market with software ecosystems and infrastructure. Top online services employ thousands of developers, each empowered to release changes multiple times per week. Large-scale intelligent systems respond to your questions, drive your car, and then learn what to do tomorrow.

This revolution is being powered by new trends in software development:

• Global teams - Not just outsourced teams that sit together in remote locations, but teams that are truly dispersed across the globe. The sun never sets on this empire of code.
• Code contribution techniques - Methods to collect code improvements from one contributor, or from thousands, refined over the last 20 years in a vast range of open source projects.
• Cloud computing - On-demand build and test systems that are the underlying engine of release speed.
• Rapid competitive evolution - Online products that respond quickly to competitors and partners, driven by daily releases and rapid adjustments instead of long-range product planning.

My SaaS company, Assembla, helps customers manage cloud-based teams and take advantage of these trends. However, our own software development techniques were not keeping up. In the fall of 2011 we had problems:

• Releases took longer as our system got bigger and there was more to test. Our two week cycle release became three weeks or more as we spent more time on testing and bug fixing.
• Releases were stressful. After a release, we found bugs in production. Actually, our users found the bugs, and then demanded that we fix them immediately.
• Competitors were achieving faster velocity with Continuous Delivery, which is a way of saying that they were kicking our butts.

The answer to our problems would not come from normal companies figuring out "best of breed" versions of the old Agile practices. We saw how Agile techniques like Scrum had helped small teams gain confidence by answering questions like "what tasks will we work on together?" But we also saw that Scrum didn't work in a distributed, cloud-based environment. It did not take full advantage of modern automation, it was confined to release iterations of a week or longer, and handicapped by reliance on Post-it notes and face-to-face, meat-to-meat interactions. Scrum failed to accommodate global teams, big projects, and rapid releases.

Instead, we studied industry leaders who are knocking the stuffing out of their competitors (some of their stories are included in this book). They do Continuous Delivery, and they have solved these problems. But we didn't start our company with Continuous Delivery. We had to study it, learn it, and build it up incrementally with tools and skills.

We began implementing this approach in early 2012, using the philosophy of "release more frequently" and incremental improvement. The results are posted below. Now we release changes about 250 times per month. We have fewer bugs in production. Without big releases, we have much less stress.

We found a new type of "Continuous Agile" software development that is:

• Continuous and non-blocking: Team members can work on their own features without waiting for someone else to debug and release, permitting each person to work in an efficient way, while at the same time allowing projects to scale to hundreds (or for some open source projects, thousands) of contributors.
• Lean: Contributors can work on one task at a time, do a good job, and finish it. Managers can "pull what's ready" to assemble a release.
• Automated: Nothing is hidden in manual build commands or Post-it note plans; everything gets put into repeatable scripts and is visible online.
• Based on managing code: It is important to manage people, but it is easier to manage code. The new Continuous Agile makes extensive use of source code management and code contribution workflows. It adds code management to the old team and task management.

You will need these techniques if you provide any type of online service, or if you have a big project with a lot of contributors, or if you are running a lean startup.

This type of development is powering the most successful online services. When we looked more closely, we found that continuous delivery was also powering larger IT operations. They are using a revolutionary technique to release tens of thousands of adjustments in the time that a competitor does one release. Almost all business products and services are now built on software and IT systems. To compete, you will need to release more frequently.