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 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, and they were kicking our butts.
In short, we had many of the same problems that you might have. We suspected that Continuous Delivery and Continuous Agile would solve these problems. We didn’t start our company with continuous delivery. We had to study it, learn it, and build it up incrementally.
Here are the results. Now we release changes about 250 times per month. We have fewer bugs in production. We have much less stress.
Now we have started working with clients, and we often see the same issues that we faced:
- Release times that take longer than expected, sometimes much longer
- Stress building up between the product-owning team and the development team while waiting for releases
- Teams that are too dynamic or too distributed for fixed-format Scrum processes
- Competitive pressure. For example, Microsoft just announced that they will move their Office 365 product to weekly, and then daily releases, which is clearly a response to the faster Google Docs release cycle.
The Structure of Continuous Agile at Assembla
In 2011 we were running a “Scrumban” process. We had scheduled releases every two weeks, but we skipped the iteration plans and asked our distributed team members to pull their own tasks. Our test environments were not standard and were often constructed by a feature team. On the plus side, we could do automated deployments with zero downtime.
You can see from the graph that progress began in 2012 and was incremental. We used continuous improvement, not a big bang. Over the next year we moved to the following structure:
Kanban task management. We have found that development teams can work effectively off an online Cardwall. They pull their own work. We do frequent reviews of the amount of work in progress to keep it manageable. However, we find that handling large backlogs is challenging, and we are building new features to address that problem.
Git-based code management with short-lived feature branches and required code review. We use the distributed continuous delivery pattern (described in this guide) which allows us to release each change after it has been tested in its own test environment.
Automated testing with on-demand test systems. Over the course of a year we invested in test infrastructure. We already did code review for each change, and this gave us leverage to ask developers for more test scripts. We use Rails unit tests and other test scripts running inside the Jenkins CI server, and we integrated Jenkins with the Assembla permissions and API. We currently use cloud computing to start complete test instances of our system for every merge request. This allows us both to run automated tests and to hand off a working system to a QA person and story owner for manual testing and review. The topology changes according to our needs.
Story-owner product management and user experience design. One person is responsible for constructing the story, for design, for “unveiling” the feature, and (theoretically) for follow-up and usage statistics.
My approach to Agile
Since I started working with distributed, open-source style teams ten years ago, I have felt stifled by conventional corporate Agile. I have never recommended Scrum-based Agile. The cycle time is too long and it requires too many meetings. It does not fit our distributed teams, or our customers’ teams.
We are a small company with people in 15 countries. The teams are dynamic, with people joining and moving around. Rather than engage in tedious rituals and hold tedious discussions about whether Agile teams need to be co-located, we just built tools to make our process work.
So it is with great satisfaction that I am able to 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.