Below we speak to our Chief Technology Officer, Dan de Sybel, about why Infectious Media doesn't do release freezes, and how this benefits us and our way of working.
We’ve always been agile. We like developing things in small stages, releasing quickly and moving on to the next set of features on the list. It’s worked well for us, allowing us to rapidly develop complex applications in a fraction of the time and at a fraction of the cost of many of our peers.
Agile is a funny beast, however. It has different flavours, incarnations and disciplines, depending on who read which book and how militant your Agile project managers are. We’ve always tried to take a relaxed approach to many aspects of Agile development, whilst sticking to its core principles, such as always releasing something at the end of a sprint cycle (we adopted the Scrum methodology) and keeping communication tight, but free-flowing. We’ve also stuck to weekly sprint cycles as we’ve found that longer than that increased the chances of sprint failure and made it harder to adapt to changing requirements from the business.
Releasing something weekly might sound tough, but once you get into the swing of things, it becomes difficult to imagine doing things more slowly. Weekly releases provides the necessary sense of urgency to allow end users to prioritise testing new features as part of their regular workload and it helps isolate any additional impacts on infrastructure that are caused by the new code, since each release is relatively small.
This did create problems for us at Christmas though. December is typically a 2 week month, as even if some people do not take holiday, you can be guaranteed that you will not be at full strength for around 2 weeks of the month. This would mean that key people would not be available or be too busy to watch the new releases as they came out and even if they did test and find problems, there may be less developer support to correct them or rollback the release.
Our solution was the same as most companies, why not just avoid releasing during this time and wait until the company was back at full strength in January? We could still carry on developing during this time, and just extend our sprint cycles to 2 or 3 weeks. However, after 2 years of working to this practice, we changed this methodology, as it did not meet our in-demand requirements any more.
The solution that ended up working for us was actually even simpler. Whilst we still schedule development work on a weekly basis, we now release as soon as that work is completed. This is more of a Kanban style of releasing and means that we release several times a week, if not several times a day. This manages the bottlenecks caused by staff holidays during Christmas considerably better and means we think about what work should be scheduled over the holiday period more effectively.
Sometimes we forget that Agile is a core set of principles and if applying them strictly causes you to end up being less agile, then something needs to change. By adapting our processes we’ve managed to find a solution that not only allows us to avoid release freezes, but has actually resulted in our release process being smarter, faster and, more importantly, easier. This last fact has meant more stable software that is more useful to the business for less cost, delivered in shorter timescales, something that any CTO can be proud of.