Relaunching your website – the last excuse for a big bang release

Creative Commons License Mario’s Planet

I really love working in small batches as it ensures timely feedback and fast realization of customer value. Usually, we release two to three times a week – each release featuring only a handful of user stories. While I got used to working in this mode over the last couple of years, it’s really impressive if you look at how different working in big batches is.

Complete UI relaunch – a small batch killer

While I found it doable to break even big changes, like a complete migration to UTF8, into small batches (and therefore small releases), one final type of project is still eludes being dealt with in small batches: A complete UI relaunch.

Completely changing the look and feel of your application cannot usually be done step by step. It would seriously break the user experience and confuse your users. So you have to modify & release every screen at once. Hardly a small batch at all. Being forced to do such a big bang release leads to a couple of ill side-effects:

  • Fear of features being left on the shelf: This is an interesting effect. Even if you’re used to releasing multiple times a week seeing a big relaunch approaching makes people feel itchy about a lot of really non-critical features or layout changes, which suddenly must be part of the relaunch. Somehow the fact that the next release after the relaunch is only a couple of days away disappears and people panic.
  • Adding new features along with the new layout: Ok, new features might be a driver for the layout changes, so they have to come along with it. But as you are touching the whole UI anyways, there’s a big temptation to start changing a lot more things than just the layout. On the one hand, this can be very good if you do cleanups and refactorings, which improve the overall structure and code quality. On the other hand, every such change increases the risk of introducing non-UI related bugs. Of course, strong unit testing helps you here – but what if your test suite is far from being perfect…?
  • Complete regression test necessary: While you can usually rely on automated tests and some clicking around for small releases, changing the complete UI suddenly requires a complete regression test. Full regression tests require code freeze periods to have a stable system under test. Such code freezes amplify the urge to add more features as it feels like a stand still – a downward spiral.

Fight for small batches

Seeing all the ill effects of big bang releases, it should be obvious that it pays to break big chunks of work down into smaller batches. While this might not be possible for such a visible change as a UI relaunch, at least factor out most of the new features and optional refactorings to keep the changes minimal. The temptation to bloat that one big release with a lot of bloat comes with drawbacks that far outweigh the hoped for benefits.

One thought on “Relaunching your website – the last excuse for a big bang release

  1. I disagree that a UI relaunch needs to be done in a big bang release. Unless you also change the system underneath (which agencies often seem to unnecessarily do), changing the UI bit by bit has also the benefit of not confusing the user too much.
    I’ve made an iterative UI relaunch twice now in my life, and it definitely beats all previous bad experiences with a big bang release. I’ve written about how I’ve done it here: http://blog.selfthinker.org/2015/12/28/going-responsive-or-the-silent-relaunch/

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.