The 12 Days of Agile Principles! Principle #3

deployments like little presents delivered frequently

Welcome to Day 3 of the 12 Days of Agile Principles, this one is pretty self explanatory:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

We like to deliver frequently in short bursts, and this enables many good things;

  • such as opportunities to offer moments of customer delight frequently,

  • such as opportunities to learn what our customers like doing with our products and adapting them accordingly - did I hear someone say A/B test?

  • such as practicing over and over how to release and get really good at it; when you get really good at releasing and can do it ‘on demand’ then you can take more risks with your products and try more crazy stuff, because you know your team can fix or change things quickly if they need to.


To quote Henrik Kniberg “If releasing is hard, we’ll release seldom, if releasing is easy we’ll release often” We aim to create a virtuous circle of releasing more and more often and easily. 

In 2001 when the principles were captured a couple of weeks was considered cutting edge.  Now many mature agile digital teams release daily, or multiple times per day. Companies like REA group, Envato and Red Bubble have multiple teams pushing code to production dozens of times a day. 


Sounds like digital paradise huh? So how do these teams achieve such frequent release nirvana? Or rather, as I’m sure many of you may be thinking: “That’s never going to work here because of [Insert list of all my technical problems]”. 

The attitude to apply is:

Do something once manually? That’s ok... 

Do the same thing twice? Maybe... 

But if you find yourself doing the same thing a third time?  Automate it!  Automate the hell out of repetitive tasks that you find yourself repeating too many times.  Automate your software builds, your deploys, and your tests and then you can be building, testing & deploying at the push of a button frequently.


Delivering working code frequently is also a practice that provides more opportunities for feedback from customers, and more opportunities for learning and changing for the team. So you can see how we are already making virtuous circles back to the other principles of satisfying customers early and welcoming change.  


Tune in again next time for Agile Principle #4 or join the conversation at @TheRebootCo


(As a cautionary tale, if you want to read what happens if you don't practice frequent releasing tune in to An Agilist's Tale Part 1)