Nukes versus Fireworks. The art of releasing often.

One of the great things about Agile is that it enables you to release code into production often, the more often the better.  At the extreme edge is continuous deployment and we will cover that in another post later on.  In this entry we are going to concentrate on the benefits of releasing code to production often and on why you should try to do it as often as possible.

If you don’t want to release the product to the public and wish to save this for a big bang type of approach it does not mean that you cannot release more often.  In this case you can release into a non-production, “preview” (aka, staging, soft launch, demo, etc.) environment.  Here you can still get all of the benefits of the above by gaining feedback from internal stakeholders and still keep your big bang release for the marketing team!  By the way this is what a lot of the big players in software do when they do agile.

Try to keep both of these kinds of release in mind as you read this and then decide which way you want to do it.  Direct to production or to a preview environment, either way you still gain huge benefits from releasing more often.    So read on…

Let’s start with why this is a good thing.

If you are releasing code into production at a frequency greater than monthly (fewer than 12 releases per year) then you are probably holding onto completed features.  If it’s done get it out the door! If you are holding completed code before it goes out the door then you are probably doing one of two things.  You are waiting to QA it until the end or you are QA’ing it when it’s complete and then merging it into the main branch.

If you are holding the code until you are at the end of your development period then you are potentially layering more uncorrected bugs on top of good code, or worse, layering bad code on top of other bad code. This is going to make bug discovery and correction much more complicated than it needs to be.  If you are QA’ing when the feature is complete then you have a higher likelihood of braking this known good code with future merges and you create more work for the regression testing when you do QA.  You do perform full regression testing, right?

Even a small increment on how often you release code into production will have an immediately tangible and positive impact on your product.  Why?  There are several reasons for this one.  You are going to find, and be able to correct, production bugs more easily because you are going to be looking at a smaller and less complicated code base than if you waited until you had all of your features completed.  You really get so see if what you delivered is what the customer (or business stake holder, or product owner, etc.) wanted, not just what you thought they asked for, think of it in terms of this classic IT cartoon,  (http://www.projectcartoon.com/cartoon/2).   You will get customer feedback on the feature very early on in the project so that you can react more quickly and address these issues as they come up rather than all at once which is the case when you wait for big releases. There are plenty more reasons but this is supposed to be a blog and not a book ;-), so maybe I’ll add some more later.

There is another way to look at the benefits of delivering code more often, you can look at it from the point of view of the different groups involved in getting this done:

Way one.  The way of the Product Owner:

• Frequent deployments to end-user provide an opportunity to get fast customer feedback
• Product requirements could change significantly if deploying to production once in every few months. By launching frequently, you could gather data from end-users earlier and apply adjustments accordingly
• Follows best Agile and Lean practices
• Exposes risks and challenges with design, data and user interface earlier in the process, allowing for course corrections along the way

Way two.  The way of the Development Team:

• You deliver value to customers more quickly
• You learn quickly
• It forces you to break big ideas into manageable pieces
• You avoid horrible merges and simplifies the merge and regression processes
• Simplifying regression shortens the regression period
• You get cleaner code to test at the end of the quarter
• Coupled with good automated testing you reduce risk
• It keeps people motivated by letting them work on new things often

“Agile teams deliver smaller and more frequent releases to customers and end users, providing more business benefit and more frequent feedback.” From Scaling Software Agility: Best Practices for Large Enterprises [Dean Leffingwell]

Way three:  The way of the Stakeholder:

• By delivering tested, working, valuable software to stakeholders regularly, you increase trust between you and the stakeholder
• Your stakeholders request a feature and soon see results
• There’s quick feedback between planning a release and getting the software
• You will also get feedback from stakeholders more quickly
• This allows you to learn and adapt

“Release early. Release often. And listen to your customers.“  From The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary [Eric S. Raymond]

Now let’s correct the possible myths and myth-conceptions of increasing the frequency of your code drops.

Releasing more often does not have to dismantle your existing release process.  If you have a working and workable code release process then you should be able to easily adapt it to accommodate more releases more often.  Although if your releases are so far apart in time that you do not yet have a repeatable process then you are going to need to tackle that problem first.

If you don’t have a repeatable formal release process look around and see if there is any other processes that you can co-opt and leverage to get you there.  One easy trick is to look at your existing hot-fix process and adopt is as you more streamlined release process for frequent releases.

You don’t have to develop features faster.  Decide on what frequency allows you to develop a reasonable feature and then use that as your new release frequency.  In other words, if you have the kind of product where a significant feature takes about a month to develop and QA, then you should release once a month.  There are always going to be features that are going to have to take multiple release cycles to complete.  Make sure you include these in your planning for a more frequent release process.  I know that this is counter to the traditional view where a sprint is 2 weeks and you release at the end of that two weeks.  If you can do that, then all the better, but not everyone can and we should all be cognizant that any SDLC has to be modified to best fit the organization using it.

Frequent releases… and who’s doing them.

• Yahoo, “large-scale corporate adoption of Scrum, which now encompasses more than 200 teams projects and over 1,500 employees in the US, Europe, and India”
• Saleforce.co, 200 + engineers
• GE Healthcare
• British Airways
• NYSE
• Homeland Defense (Yes, even the feds are doing it!)

… and who’s doing more and gone to continuous deployment

• Facebook, “releasing changes twice per day, and every week they release code from 600 engineers”
• Flickr, “10 deployments per day”
• Google
• Atlasian
• Digg.com
• WordPress
• Etsy.com

Demand Media (eHow.com, Livestrong.com, Cracked.com, IndieClick.com, eNom.com)

So as always drop me some questions and I’ll get you some answers to whatever I can.