Continuous delivery

Software update cycle: faster every day

Posted on by will

My Atari 2600 never got a firmware update. Not a single one. Neither did any of the game cartridges that came with it.

In the early days of software, ‘soft’ware was really just a different kind of hardware. It was built, packaged and shipped exactly once. If you shipped it with a bug, that bug would stay there.

‘Softer’ storage types (tapes, floppy disks, etc) and better distribution allowed software companies to release new versions more often. Many years between major versions became one or two years, but updates to a specific version were uncommon.

The internet shortened the cycle even further – turning one or two years to months for many software products, and allowing automatic updates of existing versions to fix bugs, patch security holes, and so on.

Seamless and fully-integrated update and application management technology, like the App Store for Mac, can bring the cycle down even futher – changing months to weeks between updates.

What happens when the cycle is even shorter? Then you get web products. Sites like WordPress.com or Amazon can push an updates to production servers multiple times per day.

How fast are you?

Move fast

Posted on by will

The world moves fast. Your competitors move fast with it.

Users move fast, too. Users are more fickle than ever before. This month’s UK WIRED magazine rated Twitter as “tired”. This for a service that’s only five years old with a still-growing userbase. Ouch!

In the world of web products, building and releasing beautiful and delightful products and user experiences is only half of the battle. The other half is winning (and keeping) your userbase. Your product could have a net promoter score of +80, but if it still only has 10 users, is it really successful? If you build it, they won’t necessarily come.

Users want stability and reliability. Once they have settled in to a product that solves a particular need, it’s that much harder to get their attention to yours. At the same time, and perhaps contradictorily (who said human beings were simple?), users also crave the new. New updates, new versions, new features. News, blogs and social channels thrive on the new.

The web has sped up business dramatically and continues to speed up software product innovation. It’s a race to the bottom – at some point we won’t be able to go much quicker – but we’re not at the end of that race just yet. The strategy to compete in this space, I think, has two major components:

1. Work fast. Build fast, iterate fast: improve fast.
2. Be ready for when we hit the bottom. When we can’t go faster, on what track will the next race be run? Which race can you win?

Important note: fast doesn’t mean chaotic and unplanned.

Driving innovation with agile: a short case study

Posted on by will

A prototype of the first mouse

We all know the story – but it’s still remarkably easy to forget that some of the most influential innovations in the field of personal computing, including the mouse, the laser printer, computer generated bitmap graphics and the graphical user interface, were not invented by Microsoft or Apple, but by a small research centre in the Valley called the Xerox Palo Alto Research Center (PARC).

Of course, part of the reason we all forget is that PARC are equally famous for fumbling the future, as was written in 1988, and not managing to capitalise on these innovations. For the next 20 years PARC was largely ridiculed and mostly forgotten.

Flash forward to today, and PARC, now spun off as an independent subsidiary of Xerox, is back in the big leagues and delivering a huge amount of innovations to tech startups, corporations and even the U.S. Government. Harvard Business Review have posted an interesting article on the HBR Blog about the secret to their reinventing themselves. One point stood out to me like a beacon:

Part of the magic lies in the current business model which, as Lawrence Lee, director of strategy, explained to us, relies on partnering closely with customers, inventing a minimally viable product, and collaboratively iterating from there, based on market feedback.

This is what agile, and continuous delivery, is all about: get your innovations into the hands of the customer as soon as possible, and iterate based on real feedback. It’s about “inventing a minimally viable product”, and using real feedback, real customers, real interactions, to make the next decisions that impact what your product ends up like and in what direction it goes.

Interestingly, the other ingredients to their success were People, Collaboration and Communication.

Now consider the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The basic principles that helped PARC reinvent themselves once again into a successful innovation house are the same principles that drive agile software projects. Even if they didn’t use the word ‘agile’, the engineers at PARC are living the Agile Manifesto every day.

Release it: now

Posted on by will

Release your software to real users as early as possible.

Building software for years without ever releasing any of it is like working in a kitchen and letting the food go cold and mouldy before serving it up.

Building software is a collaborative process – not just amongst you and your colleagues – or between you and your partners – but between you and your users. Feedback from real users helps you guide the future of your product and your immediate investments. It helps you prioritise and optimise. Making product decisions without real user feedback is quite often, I think, guesswork. Yes, it’s (hopefully) educated guesswork – but it’s guesswork all the same.

You can learn a lot from user testing and user research prior to release – and there’s no way you would want to skip these steps – but nothing can replace the feedback you get when real people use your product, with real use cases, under real load.

If you see that you’ve been sitting on the latest version of your product for months without any of it hitting a user, or if you find yourself wanting to squeeze “just one more feature” in before you drop the release, then stop and think: can I give my users meaningful, measurable value with this release? If so, then release it. Now!

Continuous delivery: release early, release often

Posted on by will

If you’re in the business of building a car, you only really only have one chance to get it right. Those years of research and development, trials, testing, marketing and building culminate in a single, big release – your car launch. You only have one chance because by the time your customers drive your car away from the lot, it’s too late to fix that overheating problem with the brakes, or add another 0.5L engine capacity. Shame.

Software used to be the same way. A software project would be analysed, specified, analysed again, specified again, built and re-built and finally, after months or years of development, would be burned onto a CD or floppy disks, put in a box and sent to a store. Before the internet getting updates to software was tricky. You had just one shot to get it right.

Today, we live in a very different software world – especially true for those of us working on web products. With the internet we have a delivery immediacy unlike any other product manufacturing system in the world. We can make a change today and our customers see it in their product, today. You can add a new feature today and start generating new revenue or new customer acquisitions tomorrow.

It goes further. You can release a feature today, and watch, in real time, how your users interact with it. If your key metrics go down, you can roll the feature back out. If there’s a problem, you can either fix it quickly, or roll it back. You have the power to interact directly with your customers immediately over the best channel possible: the product itself.

This is what continuous delivery is all about. It’s like a beautiful gift for any product developer, and I think not making the most of it is a waste of that gift. Release early, release often.

Darwin and the theory of software evolution

Posted on by will
Bower bird

Female bower birds prefer males with colourful blue tail feathers and an impressive nest filled with lots of blue ornaments. To a bower bird, the brightness and quality of your tail, as well as your ability to gather a stunning assortment of blue nest decorations, indicates how healthy and strong you are, and how likely your genes are to produce equally strong and healthy offspring. In other words, a bigger tail and a cooler house equals more sex, which equals more children. Your genes live on.

Generation after generation the strongest genes survive, the weakest ones are killed off, and the species evolves – better and better. It’s survival of the fittest. Or, perhaps even more apt, survival of the most effective.

Good software product development tends to emulate Darwin’s evolution. Software is built, released, used and measured. The successful features, the heavily used features, the most often talked about features receive more development, more design, more attention; the least used are left alone, watered down or removed entirely. Survival of the most effective.

On the web we have the powerful ability to accelerate the evolution. We can release software updates multiple times per day. Design – code – release – measure – rinse. Repeat. Techniques such as A/B testing accelerate it even more: which is more effective? Text link or graphical link? Blue feathers or green feathers? Big nest or bigger nest? Survival of the most effective.

For the male bower bird, just as for software products, the audience (user) is critical. Every decision the bower bird makes will be judged by the female. It doesn’t matter if the nest is made of wire instead of twigs, or if the bower produced a new nest creation framework. The female bower doesn’t care; that’s not what she makes her decision based on.

Is your product evolving? Who is your audience, and who are you making your product decisions for? Are they the same?