How fast do you want software released?
I was part of a discussion this week week about the velocity of production software deployments. I didn’t use velocity in the context of estimating software but rather the benefits of a regular cadence to releases and the focus it brings to the testing effort. The velocity of the team affects the frequency of production changes and thus in a sense affects the overall risk to the organization for disruption to existing services. If we release software too quickly, I believe we increase the risk of service disruption and create inefficiencies in system-level testing. If we release software too slowly then we increase the risk of losing competitively in the marketplace as well as losing customers.
Boris from GoldenEye knew what he liked.
This wasn’t a discussion about agile software development principles.
For my part, I was curious about the relationship of production software releases,production defects created by those releases, and the testing effort required for approval. Maybe velocity was the wrong term to use based on its agile methodology definition. My focus was on the frequency of change events to the production environment. In the most basic form, software releases can arranged by individual unit (feature/bug). Each time there is a production release it requires at a minimum unit testing for the bug or feature that is new or has changed. But when we don’t do some level of full system testing we may miss items that are broken as result of the code change. All production releases by nature have some element of risk to disrupt current services.
What’s the right software release frequency?
Obviously the answer to this question depends on a variety of factors. Software and business teams make choices and decision about how they answer the question. I look for a balance to provide support in the following areas:
- Quality Assurance – The testing effort should have time focus on feature and system-level testing. Full system testing should reduce the risk of introducing new bugs into production as result of the new code.
- Maintenance window – Excluding full system outages, the maintenance windows provide an agreed-to time for production updates. So if the maintenance windows are every other week then the software release schedule should not exceed every other week.
- Priority – Not all production defects require immediate resolution. The balance is to fix priority defects in a timely manner but not so frequently that it increases the risk and pressure associated with quality assurance thoroughness.
Remember what it is all about.
The point of velocity is not to tick a check-list that we have a process. The velocity does have benefits with estimating. But the real value is to provide a regular cadence of features with the highest quality to the customer. Most of all, the customer should understand the flow and be part of the process.
Onward and upward.