Big Bang Releases

What is a “Big Bang” release?

This is when a team works for several months on a project with the intention of pushing it live in one big product creation event.

Note that Big Bang is not necessarily the same as Waterfall, but it is an all too common consequence of Waterfall.  But it’s not limited to Waterfall.  Scrum teams can actually be forced into Big Bang releases too.

Why is this a problem?

Because it almost never goes well.  There is usually severe pressure on the date because these big releases just tend to get bigger (if there’s only this one release in the foreseeable future, it is simply not conceivable to management to wait for the next one to get their favorite feature in), and pretty soon you’re either dealing with big slips or painful cuts in functionality.

Further, with a Big Bang release, there is rarely time planned in to adapt to what you learn once you start getting live data.  More often than not, things don’t work quite like you expect, but now it’s too late.

Also, with so much change at once, the site stability often suffers as you try to find and fix all the problems you only find once you go live, and even if there’s no real issue with stability, there is often a backlash from users because of too much change at once.

So why does this happen?

There can be several reasons.

Sometimes marketing wants to do a big launch event so they think nobody can see it until they’re ready.  Fortunately we don’t do big launch events nearly as much as we used to, but even if you do, you don’t want to confuse marketing big bang with product big bang.  It is still better to push the software progressively, even if you push it incrementally but dark so customers don’t see it.

Sometimes an exec has a big aggressive date and the team thinks that the best way to meet that date is to maximize development time, and minimize test and release time.  I know it’s counter-intuitive, but this just isn’t how software works.  If you really want to hit that big date, the best thing you can do is build and deploy incrementally.  Don’t confuse delivery dates with big bang process.

Finally, sometimes the company insists on a project review or oversight process that effectively pushes the team to waterfall and hence Big Bang.  Especially big companies.  For example, they will say “you can explore this idea for a while, but before you start doing anything real, you need to have an executive review.”  And then before you actually release anything, they may want yet another exec review.  So you can see how this form of oversight can push the team to Waterfall.  In this case, you may need to still do the dog-and-pony show for the execs, but don’t let that stop you from doing what you need to do.  In fact, if you bring prototypes and real user feedback to that exec review, you’ll have a much better chance of making a great impression.   And then you can still build, deploy and test incrementally.

So if someone tells you that you need to release your project as a Big Bang, do whatever you can to avoid the fate of so many Big Bang projects by designing, building, testing and releasing incrementally.