Software Release Management. It’s more than an IT thing.

This is about IT and Business alignment.
I’m fortunate enough to have worked in two different functional areas of a business: IT and Marketing. I can say with 100% confidence that business owners and stakeholders of software releases should be more concerned and involved in the IT release management process. The typical release process covers areas such as requirements specification, feature prioritization, business case modeling, and go-live deployment communication. It’s a set of tasks intended to oversee the requirements, development, testing, and deployment of software releases. Sounds very IT, but it should be a shared business process.

Release management is about adding value.
Release Management is also about how IT and business owners engage in communication that benefits the stakeholders and customers of the business. A business owner could be the CFO, CMO, product manager, finance manager, procurement agent, etc. It’s someone who champions and justifies the contents of a release. An engaged business owner has a chance to more positively influence the results of the release.

I’m not saying they need to know all the details of the software development cycle. I am saying they need to help with defining the process such that it maximizes the potential of the organization. One of the key traits of a successful leader is making success achievable by others. They can do this in the software development cycle by making sure that the process is free of unnecessary work and is efficient in how often work is output.

Mike Sutton and Tym Moore provide a great list of practical ways to improve software release management for CIO.com One key point of Sutton and Moore is that establishing a regular release cycle is vital because:

• It creates a predictable timetable for when stakeholders can expect to receive functionality. This creates confidence and allows the team to focus more on the content of the release.
• It creates a routine for all functional teams to align their efforts.
• It gives clients confidence that your business is regularly delivering new value to the marketplace.

Think features, not projects.
Here’s the rub. To get to regular release cycles (such as every six weeks), your software development process needs to focus on delivering features of work rather than projects of work. Projects by definition have a variable level of scope which means that delivery dates will also be variable. Content for regulatory requirements, compliance issues, new features, or defect fixes are easier to deliver when they split into several smaller units of work effort. It’s a similar the concept of memorizing larger lists by “chunking” the list into smaller groups.

That’s a paradigm shift for many traditional project organizations. But it’s a way to encourage lightweight processes and focus more on delivering value to the client quicker. Salesforce.com discusses release cycles that were becoming longer and delivering less before they turned to a process focused on smaller and regular releases. They saw an immediate increase in the number of features delivered per team and a reduction in the days between releases. Amazon.com, the largest online retailer, also uses regular release cycles.

At then end of the day it’s about efficiency and work output.
Automated machinery is installed on plant production floors for this very reason. The machines produce units of output at predefined intervals. This maximizes value to the business and clients. Our software release output should aim to be the same way. It’s definitely more than an IT thing. It’s just good business.