Last Friday, we talked about how the capital-A-Agile movement managed to lose its way somewhere along the line, and we introduced the principle that true agility derives from your software, not your process. This week, we want to expand on that by discussing some concrete features that your software should have in order to easily adapt to changing business conditions. In the spirit of the Agile movement, we present a manifesto for agile software.
Agile software must be modular and abstract
Embracing change means that your software needs to be easily changeable. Following the SOLID principles is a good place to start. If you build your applications out of well-factored, re-usable abstractions and components, you will be able to modify or replace them down the line quickly and without undue risk. Consider utilizing an Inversion of Control Container to facilitate this type of design.
Agile software must be releasable at all times
Software constantly changes. Every developer checkin represents a different version of the software. Ideally, every single such version should be releasable to production. Don’t just look to have working software at the end of a project, or even at the end of a sprint; instead strive to keep your software working all the time. Avoid the temptation to create a branch to build a new feature, instead make small changes in trunk that keep the software working but move you closer toward your goal. Consider branching by abstraction to slowly build up major features.
Agile software must be deployed regularly and frequently.
Frequent deployment is the key to delivering change. If your changes to the software don’t make it to production in a timely fashion, the whole process breaks down. Your changes aren’t adding value for your users as soon as they could. You aren’t getting feedback from your users as fast as you should. Deploying on a regular, frequent schedule creates a rhythm to your workflow – that rhythm should define your sprints. Deploying daily may be excessive, but once a month is probably too long to wait.
Agile software must be easy to build, deploy, and configure.
Going from nothing to a deployable application should be a two-step process:
- Check out the project from source control
- Run a simple build command
Building the application should not require a specially configured build machine or particular continuous integration software. Deployment should be a one-click or one-command operation, ideally a simple XCOPY to the target machine. Deployment should not blow away existing configuration settings, which should be stored in the %APPDATA% or %PROGRAMDATA% folders, or better yet, in a central configuration service.
Agile software must be backwards and forwards compatible.
Frequent releases mean frequent rollbacks. They mean that you won’t have the luxury of doing a big bang rollout of all the applications in your system at once. To handle the volatility of a truly agile environment, your applications will need to be able to interoperable with slightly newer and slightly older versions of themselves and other applications in your system. When processes communicate, use a serialization format that allows for compatibility, like google protocol buffers. When reading/writing configuration data, make sure that the previous and next versions will be able to do the same.
These concepts are all derived from our first principle of DevOps — that software should be simple to operate and easy to change. If you want to make your organization more agile, start by introducing these features into your software, rather than trying to modify your process. We think you’ll find that an agile process flows naturally from agile software. In fact, we think software agility is a prerequisite for process agility and, more importantly, business agility.
