The book Unblock! A Guide to the New Continuous Agile by Andy Singleton provides ideas and practices for doing distributed cloud-based development with continuous delivery. Andy described in the book how you can build, test, and frequently release code, and how continuous agile can be used on top of continuous delivery with strategies for managing teams, products, and enterprises in a continuous delivery environment.
InfoQ did an interview with Andy about what continuous agile is, how it differs from Scrum, how to scale software development using a "matrix of services", working with story owners and why you should do happiness surveys for continuous improvement.
InfoQ: Why did you write a book about new continuous agile?
Andy: Because it’s dynamite material that will rescue readers from the old, boring Scrum cycles. Thousands of the world’s best software engineers and technology companies are figuring out how to use cloud computing to build software with amazing speed and scale, and this book dives into the middle of it. At Assembla, I work with distributed teams. We have 10,000 teams using our online workspaces, and I personally run a team of 30 people located in 10 different countries. The Scrum process is not good for distributed teams because it requires a lot of meetings, so I have been experimenting with alternatives. About two years ago we moved Assembla from bi-weekly releases to continuous delivery. This gave us a huge reduction in stress, and it helped us increase the quality of our product by hiding and “unveiling” features at the right time. The patterns we used to test and merge code were different from the patterns described in the “Continuous Delivery” book by Jez Humble, and closer to the norm for other SaaS companies, so I started making diagrams of code flow, and blogging about that. As our developers got better, they put a lot of pressure on me to speed up and improve our product management. So continuous, metric-driven product management became another area of research. Finally, I started interviewing bigger and better development teams about their approach to continuous delivery and continuous agile. I had a major revelation after talking to some guys from Google, and then going to see the VP of Engineering at Hubspot. They were working at very different scales – 100 engineers at Hubspot, and 15,000 engineers at Google – but they were using a similar process which I dubbed MAXOS. This is continuous delivery run on hundreds or thousands of components in parallel, and it’s an important part of the cloud computing revolution.
InfoQ: The book is titled "Unblock! A Guide to the New Continuous Agile". What do you mean with "unblock"?
Andy: If you can’t release your code, you are blocked. We’re trying to unblock. This makes your development more reliable and scalable since problems from one team or feature don’t block everyone else.
InfoQ: Can you share how you view new continuous agile? What makes it different from for instance doing frequent releases or continuous delivery?
Andy: Continuous delivery is the most important building block of continuous agile. Continuous delivery is a way to build, test, and release code. Continuous agile builds on that with strategies for managing teams, products, and enterprises in a continuous delivery environment. So, we start with continuous delivery of code, and then we build it up into continuous agile by adding related tactics for teams, products, and enterprises.
InfoQ: What are the main differences between new continuous agile and Scrum? Can they be used together?
Andy: All agile methods share similar tactics, such as user stories, frequent releases, and retrospectives to improve the process. However, Scrum blocks everyone into the same periodic release cycle, and forces them to “self organize” into “multifunctional teams” to fight their way out of this box. Continuous agile is a newer, simpler and more scalable process that lets each person – especially tech leads and product managers – move forward at an optimal pace with fewer rituals. Fortunately, it is easy to transition from Scrum, to scrumban, to Kanban and continuous agile, just by removing extra Scrum rituals, adding some test layers, and becoming leaner. I illustrate this progression in the book.
Fundamentally, an agile process with many releases works better than a waterfall process with one big release because when you do more releases, you get better with practice. Using this theory, you should have more productivity and lower stress as you release more frequently. In practice, if you give developers the opportunity to release each change, they release more and more frequently – and much more frequently than Scrum teams. This makes the releases smaller and easier to debug.
The new continuous agile differs from Scrum in some underlying philosophies. Scrum is a set of recommendations for team management. Everything flows from the team. Continuous delivery and continuous agile make much heavier use of “technical practices” – machinery to build, test, deploy, present, and measure software. With cloud computing, we are doing what farmers and coal miners have done, increasing individual productivity with more machines and bigger machines. There is a limit to the gains from improved team management, but there is no ultimate limit to the gains from automation.
InfoQ: In your book you described the "matrix of services" or "MAXOS". Can you explain what it is and how organizations can use it to scale software development?
Andy: MAXOS is short for “MAtriX Of Services.” In a MAXOS architecture, you chop your software up into a bunch of Web services, and you assign each service to a development team that runs continuous delivery. So, you are running continuous delivery on hundreds or thousands of components in parallel. MAXOS solves some huge and hugely expensive problems. It allows you to organize big systems because you don’t have to figure out all of the dependencies in your project plan. Instead, you use a continuous test and integration system that finds dependency problems between related services, and notifies the responsible teams. The genius of this approach is that the testing machine can actually replace a lot of managers. It’s a revolutionary, mind-blowing change.
I dubbed this “MAXOS” so that I could position it against SAFe (Scaled Agile Framework from Dean Leffingwell). SAFe is the naïve, non-automated approach to stacking management on top of a bunch of scrum teams, and none of the really good technology companies do it that way. They don’t stack up management. They automate it away.
InfoQ: Can you mention some of the benefits from doing continuous agile delivery?
Andy: Continuous agile eliminates the problem of stressful or late releases. This is probably the biggest benefit for development teams, who often suffer greatly from stressful releases. It’s also a benefit for managers that suffer from late releases. We are always releasing, so it becomes easy. I describe tactics to “unveil” new features at the right time, and to focus efforts on the most valuable features.
You will need continuous agile if you are running a lean startup, or lean product development, or a marketing process with frequent measurements and adjustments. Continuous agile gives you an opportunity to conquer the competition through faster delivery and fit. If your competitors are gaining on you with a faster development cycle, continuous agile may help you catch up.
Continuous agile is also important if you are building a big system with many parts. In the past, this was a very costly and risky endeavor, as described in the book “Mythical Man Month.” The big silicon valley companies that have conquered this problem with a continuous agile process that I call MAXOS – MatriX Of Services.
InfoQ: You stated in your book that "code review is the most effective way to get tests". Can you explain what you mean with this?
Andy: Continuous delivery requires automated tests. Before you release a change, you run your change through a series of test layers which apply automated tests. Programmers must write these tests. Some development managers try to browbeat their developers into writing these tests. Browbeating doesn’t work. Mandatory code review is a much more reliable way to get tests. You can ask your reviewers to check for the automated test that should come with any new feature or bug fix. If the change doesn’t come with related automated tests, the reviewer rejects it and sends it back. This always works and it works immediately.
I also noticed that in successful continuous delivery shops, the programmer makes the decision to release. The programmer must test the change and then push a button to start the release process. They can’t just send a change to a QA person and expect the QA person to finish the testing and make a decision. This responsibility gives programmers a strong incentive to build good tests and test frameworks. It’s a second layer of incentive to provide good automated testing, on top of code review.
InfoQ: At Assembla you have story owners instead of product owners. Why did you adopt this, and what makes it different?
Andy: A story owner doesn’t just plan a feature and hand it off for design and development. A story owner works with developers to design, beta test, unveil, and measure response. It’s more work, but we get a better feature. I think that story owners are necessary because we need to make better features in order to compete, and because we need to pay more attention to usage data around each feature.
InfoQ: Can you elaborate how teams can improve continuously using happiness surveys? You mentioned that you prefer them over retrospectives, can you explain why?
Andy: You want to continuously improve your process. A retrospective meeting is designed to help you improve your process by asking “What went well with recent releases? What didn’t work? What should we improve over the next few weeks?” It’s great in theory, but in practice, it’s often boring and annoying. I’m not sure why. We got better results from a “happiness survey” format that I learned about from Henrik Kniberg and Jeff Sutherland. This asks slightly different questions: “What feels best now? What feels worst now? What would increase your happiness?” You would expect this would turn up irrelevant personal problems, but in practice, it leads to real actions that increase productivity. And, you can do it any time without a release schedule.
About the Book Author
Andy Singleton is the founder of Assembla, a SaaS company that helps distributed software teams work together. He previously founded PowerSteering Software, a provider of enterprise project management systems, and Cambridge Interactive, an e-business consultancy. In 1992 he attempted to discover the secrets of evolution and innovation by filling a house with racks of single-board computers and running a "meta-genetic algorithm" to discover the perfect learning parameters. He has continued to study methods for innovation, and has released more than 20 software and information service products since receiving a BA degree from Harvard.
