Shipping Enterprise Software

Problem

Our company produces Enterprise Software but when you look at Enterprise Software delivery models, they are usually multi-year or 18-month models and you don't get a new version of a sequel server or exchange server on your data center every couple of weeks. However, there's huge value in being able to push your product regularly. The value for a startup is that they can push their product as early as possible to get feedback. You don't want to just assume that your plans for the next 18 months are going to be what the market wants.

Actions taken

My company decided to drive the notion of quality and testing at even the lowest level, and throughout the entire stack. We have a continuous integration and delivery system, and every line of code written at my company has to be unit tested, system tested and integration tested, and this has to be done by the software engineer who wrote the code. We also ship our code every two weeks. At the end of the second week, we pick a build, we hammer it for two weeks, and if we find any bugs we'll fix them. When all of this done, we ship the build and then monitor it. If anything pops up, we're then able to quickly resolve the issue. As a result of our rapid shipping, we cut up larger builds into smaller pieces, so we can deliver these pieces to the customer earlier on.

Lessons learned

Feedback is very important and for customers it's amazing. As a customer, you are then getting continuous value and you are no longer kept on something for two years before suddenly getting an upgrade. In addition, most importantly, this model improves quality as bugs can be picked up on faster and more easily.
You can read more about our model here