Even though my organization has been practicing “agile” for several years, I have witnessed a seismic shift in what that means over the last 15 months. We have shifted from Sprint Teams running two-week Sprints and releasing every other Sprint cycle to an interrupt-driven Kanban “pull” model with no strictly time-boxed development cycle where we release twice a week, whatever is ready. This is just a step along the road to fully automated Continuous Delivery for us, though. We’re learning as we go. Our focus right now is ruthlessly stripping our manual release process to its essence, then automating what’s left.
Even though we’re focused on optimization of a semi-manual release process, we’re thinking about what else we need to do to improve our game. We’re not just thinking about release process. We’re still defining our development philosophy is, how we can create an infrastructure in which we can experiment, and what techniques we can employ now that improve our flexibility and give us more options for future experimentation.
It’s important to understand there’s nothing particularly earth shattering within the book. It is not a detailed step-by-step guide that will solve all your problems and bring you limitless unicorn dust and rainbows. Instead, it is a well considered treatment of the subject of continuous improvement, and a good survey of successful tactics for keeping continuous improvement momentum going, written in plain language. Many of the ideas contained in the guide are variations of ideas we’ve floated to each other at work. If you’ve spent any amount of time reading about Continuous Improvement, Continuous Integration, Continuous Deployment, et al then you’ve seen most of these ideas elsewhere. This is just a succinct summary of related ideas collected in one text.
The best part of the book for me was the discussion of Feature Switches. It is simultaneously elegantly simple and infinitely flexible. The immediate gain to employing this tactic is that you gain the capacity to fully and completely roll out a new feature to production in small steps, as it’s completed, while still ensuring it is fully tested along the way. It decouples the development of a feature from the release cycle. It negates the need for messy long-lived feature branches while the feature is completed. It *also* decouples feature development from documentation and marketing. The implication being that, with this little technique, we gain the capability to unblock forward motion in development because we can complete a feature, have it properly tested and in production, and move on to other tasks independent of its unveiling to end users. Additionally, Feature Switches provide other new capabilities: a means to set up and conduct A/B testing, and Canary Releases. Reading the Continuous Agile book was very much an “Aha!” moment, as I realized this.
Like I warned about the book, though, this technique isn’t a magic pill. There’s a downside: accumulation of extraneous cruft. Making use of this feature implies a commitment to later remove the switch when it’s no longer needed, lest your codebase eventually collapse under the weight of hundreds of switches that no one remembers why they exist or whether they can be removed. I feel like we have a pretty simple, elegant method for dealing with that, though. Our rule is to always create an “undo” ticket any time we knowingly create technical debt such as this. The belief is if we track our bad decisions, we won’t forget about them, and we can keep it on the work list. I suppose, alternatively, one could argue the definition of “done” isn’t met until the feature is enabled and the switch is removed, thus the original ticket remains open. However you choose to tackle that detail, this technique has profound implications for a development team’s flexibility and velocity. It’s one of those hallmark attributes of a mature agile team.