This post is from the XebiaLabs blog and has not been updated since the original publish date.
The Reality of Software Releases
Many organizations model software delivery as if it happens in a perfectly repeatable pattern where the features that are initially planned for a release are always the features that are actually delivered to Production when the release is complete. But the reality of software releases is more complicated than that. In the real world, it’s hard to predict the delivery of planned features. One reason is that development teams don’t deliver every code change to QA at the same time; instead, delivery is staggered as the team finishes features and prepares them for testing. But at the same time, the QA team starts to find bugs in the features that have already been delivered, which starts an iterative cycle of code changes and re-testing. The looping cycle of Development-QA rework isn’t the only factor that makes it hard to predict which features will make it into the final release to Production. Delivery becomes even more unpredictable when surprise work is inserted into a release. Hotfixes, patches, emergency features for important customers—these “impact events” happen at every organization. They impact what the release will contain, and they often impact the timeline for delivering the release to Production. The reality of software releases is this: when you can’t track the events that prevent teams from delivering what they originally planned, features drop out without stakeholders knowing it, features are partially delivered, and schedules slip. In addition, you get failed deployments, cost overruns, and disappointed customers.