We have all seen the press releases come out. The CEO of some big organisation proudly announces that with this new agility thing they are now able to release to market every three months instead of yearly. Great news isn't it? Great endorsement of agile techniques, isn't it? Have you ever worked in one of those organisations? What is it like working in the delivery teams for one of those organisations? Is it, as the press release seems to indicate, some sort of IT workers' paradise where features flow easily into production and there are smiles and profits for all?

Or does it feel like an endless treadmill where releasing every three months just means jumping through all the hoops you had to jump through for the yearly releases but now instead of doing it once a year you are doing it all the time? Where the nightmare month you used to have once a year to push the release kicking and screaming out the door is now your normal workload? Chances are, it's not the first one. Feeling burned out? Are we achieving our results by throwing away one of our key principles - the principle of sustainable pace?

Faster releases is one of the standard agile sales pitches - use agile and you can release to market faster. And that's true..sort of. There's a catch. The organisation's systems aren't set up to handle fast releases. They have no production-like test environments, the environments they do have are unstable and unavailable, they have little automated testing, they have strict processes around deployment, there are mountains of paperwork to do. All this is manageable on a yearly cycle, after all that what it's designed to support, but if you speed up the cycle without fixing the system, you create a mountain of wasted effort. 

What typically happens is that the organisation decides to do faster releases. The teams set to work building features. The release happens after a mammoth effort by all concerned. The teams emerge from the release saying "Boy, that was a lot of work, we really need to fix some stuff for next time". They add "automated testing, better test environments, change release process" and a bunch of other stuff to an improvement board. 

Then nothing changes because the next release is just around the corner and no one has any time. 

How many times have you done a post release review and heard "we couldn't improve our automated test coverage because we had so much manual testing to do for the next release." "We couldn't improve the test environments because we spent all of our time keeping the environment up to meet the release deadline." "We couldn't improve the release process because we spent so long following the process to get the release out." I'm betting it's more than once. 

By focusing on fast releases without fixing the underlying system, we put the teams under continual delivery pressure which means they don't have time to fix the system. The system becomes a positive feedback loop where delivery pressure caused by system problems causes further breakdowns in the system because no one has time to fix the system, which in turn leads to more delivery pressure as the work required to get stuff to production increases. 

We also generate masses of waste as teams become loaded up with release managers and project managers and integration managers and build managers and a whole host of people who are only there to manage the release process. This makes releases even more expensive than they were before. 

We are doing it wrong. This is harming organisations. It is harming people.

Fast releases are an end goal, not a first step. Fast releases happen when you improve your systems to enable fast releases. They don't just happen because some one says so or because we are now working in scrum teams.

What we should be working towards is making releases effortless, not fast. If you can release effortlessly, you will naturally release fast. Effortless enables fast. Fast does not enable effortless. In fact fast blocks effortless. Application of agile principles will let you improve your system to the point where it is possible to release frequently.

So how do we get to fast releases then? By looking at our current process and asking "what is preventing us from releasing more frequently now". Work out what needs to change to enable effortless releasing. Then fix it. Need investment in automated testing? Then invest in it. Make time in the next release (on the old, slow schedule so that you aren't under increased pressure) to fix it. Don't ramp up the pressure, ramp it down to give people time. Include less features. Give people space to change the system. 

Once that change is made, look at your process again and ask yourselves "with this change, can we sustainably release any faster than we could before?" Maybe the answer is yes, maybe we think we can now release every 9 months while keeping the pressure the same. Great we have made some progress. Maybe the answer is still no. Maybe there is more to change before we can see results. In either case, look at the process you have now and ask again "what is preventing us from releasing faster than we are now?" Identify the next problem or set of problems and fix them. Then repeat, and repeat and repeat. 

Keep repeating that improvement cycle and you will find that your release time comes down without putting the teams under continual release pressure because you are fixing the system, not just trying to cram more stuff through the old system. You are making your releases effortless. 

But what about the lean principle of reducing the water level to expose the rocks? That's often one of the reasons given for moving to a faster release cycle straight away - if we make our releases faster, it will expose the problems so they can be fixed. The problem is that we reduce the water level too fast. Yes we expose all the problems but the water level is so low that nothing can flow. All we do is crash into the first rock and tear a huge hole in the bottom of our boat so we are too busy trying to keep the boat from sinking that we don't have time to think about removing any of the rocks.

In this case, the rocks are already exposed. Ask anyone who has survived one release in the organisation and they will be able to list the top five things that will prevent a faster release. They may even be able to give you a top 50. We don't need to lower the water level to see the rocks.

Once we have removed the big, visible rocks, we can start progressively lowering the water level to expose more and more rocks. Moving from yearly releases to nine monthly, from nine monthly to six monthly and so on. Keep lowering the water and removing the rocks as they are exposed. 

Achieving faster releases is not something the organisation can just do by decree. Actually they can, by making everyone work really, really hard all the time and generating masses of waste. Achieving faster releases in a way that is sustainable is a different matter.

Don't just jump straight to the end state. This is a journey. It will take time, it will take a significant investment. But the view, when you get there, is awesome.

My good friend Dan Prager has recently published an article looking at this problem as well and has some great suggestions for tools/techniques and most importantly mindsets to help resolve it. Check it out - Coaching for Automation Success