Continual Release

Beck defined stories as the smallest possible unit of value to a business. He showed that continuously delivering incremental enhancements to a product massively reduced risk, and as a side effect enhanced team productivity and product quality and reduced time to market.

Before this we only had ‘requirements’, and the concept wasn’t well understood. We had a product specification, without having identified the concept of a product. We ‘gathered’ these requirements from users, without having identified the concept of  a product owner. We would write these requirements and treat them as if they were correct, despite mountains of evidence to the contrary — human fallibility and the effects of time were completely ignored.

Beck taught us that requirements are rarely correct, complete, or static, and therefore we shouldn’t spend a lot of effort on specifying them.

A product specification is less like an architect’s model of a building, and more like Hollywood’s movie making process. The movie you end up with is rarely anything like the one that was started.

Now that we have reached the level where we have grasped what it is that we are actually doing — we are developing products. And, we know how to do this — reduce risk, increase quality, maintain a business approach to spending decisions, hire the best people available.

But, we still find that despite the revolution Beck inspired, we are still screwed, because the ops department can’t get their head out of their collective rectums long enough to realise that we are no longer developing megalithic stovepipe architectures. We are trying to deliver tiny fragments of software — continually.

What’s the point in having a story that provides business benefit that I can implement in 10 minutes if the bastards who control the metal won’t let me deploy except in 3 month windows?

Either we have over optimised the development process, or the buggers in ops are retarded and need to be fired. Continual Release.

Of course, there are plenty of places where continual release isn’t a possibility — air traffic control, nuclear reactors, pacemakers, but most software isn’t written for these environments. Most software is written in java. Most non-embedded software runs in some variety of corporate IT environment where continuous release isn’t just possible, it’s highly desirable.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your 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 )

Google+ photo

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

Connecting to %s