Why Continuous Agile?
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.
What you will get from this book
This book will help you win with more frequent releases. It will share what we learned at Assembla, and what market-winning companies have told us about their success in moving toward Continuous Delivery and Continuous Agile. It contains terms that will help you discuss your strategy and tactics with your development teams, managers, partners, and investors. You will learn about "test layering," "feature switches," "unveil," "learn before launch," and many other tactics.
In this guide you will find:
An overview of Agile techniques for task management, code management, and testing. Most people find one method that works and stick to it like dogma. We will show you more options. The overview will make you a smarter software developer who can pick the right tactics, and switch tactics at the right time.
Continuous Delivery. When I first heard about Kanban with continuous delivery - releasing every change - I thought it was magic. How would you test it? The answers are very practical. We break continuous delivery into components you can adopt.
A way to evolve your project from simple roadmapping and prototyping all the way to full continuous release. This is the "beyond scrum roadmap." It provides a high-speed alternative to more laborious project planning.
Recommendations for handling the new world of distributed teams and team building.
Revolutionary techniques to solve the most expensive problem in tech: scaling to larger teams and working productively in big software projects.
Continuous product management that will help your business keep up with your accelerating continuous development.
You will also find unique opinions that I have developed over decades of working with startup teams, pushing the boundaries of Internet technology starting in 1994, moving to SaaS in 1998, and building out distributed teams on the 2000's. This isn't the same corporate agile BS. It comes from first principles.
To round off these insights, we have included stories from other organizations that figured out how to thrash their competitors by releasing more frequently. Co-authors contributed ideas and chapters that expanded my understanding.
It is with great satisfaction that I present this guide to Continuous Agile. It connects innovations in Continuous Delivery with the traditions of Agile, in a way that is compatible with existing Scrum teams, but also works for modern, cloud-based teams.