Shipping Doesn’t Mean Done

Shipping doesn’t mean done. I read the phrase recently and it has been bouncing around in my head for while.

This is the mind shift that needs to take place for devops to be successful. There are so many definitions of done in software development, but we are used to the final arbiter of ‘doneness’ being shipping. We’ve shipped the feature so it’s done now whether we like it or not right?

Devops says no. Shipping does not mean done. It just means the feature is done enough to show to customers and get feedback on it. It means it is ready for the tweaking it is going to need in order to really add value.

If we don’t get this – and mean gut level get it, not just mental ascent get it – devops is going to be hard. For example: If your delivery schedule looks like this, you are probably still thinking of shipping as meaning done.

The problem is devops doesn’t just mean the developers are on call when something goes wrong. It means the schedule should look more like this

See? Shipping doesn’t mean done. There is so much value that we can add (as testers and developers) after shipping. If we don’t explicitly put that in the schedule, we are missing out on a lot of the benefits of devops.

And just to make sure I’m not putting too fine of a point on it, the key thing I’m talking about here is the schedule. If we don’t build that ‘after release’ time into the schedule, we are not going to be successful at devops.

When our team schedules look as if shipping means we are done, someone somewhere isn’t understanding or internalizing what we are trying to do in devops. We need to build time into the schedule for experimenting with and improving ‘in production’ features.  If we don’t do that we might as well just go back to waterfall, because then at least you are theoretically reducing the amount of buggy code you foist on your customers.

Don’t forget. Shipping doesn’t mean done!