Releases and Changes

“Best Practice” in 2000(?)

I remember being taught in an ITIL^® V2 class that higher quality is one of the principle benefits of grouping changes into releases. This is principally due to more efficient use of testing. ITIL mentions as benefits (Service Support §9.4.1):

• a greater success rate in the Release of hardware and software
• assurance that the hardware and software in live use is of good (or known) quality
• better use of User resources because of combined efforts when testing new Releases
• minimization of regression-testing requirements, offering greater coverage than is possible with small changes that occur frequently or too close together.

And yet, the partisans of such approaches as extreme programming (XP) or continuous delivery claim precisely the opposite. Smaller chunks of software released frequently are much easier to manage and to ensure high quality. Has something changed in the very few years separating these two approaches or is one approach right and the other wrong? Or is the issue largely one of scope and applicability, making the apparent conflict a case of apples and oranges?

What ITIL Assumes

The argument advanced in ITIL V2 is based on a set of assumptions about how software is developed, tested and deployed:

• Software was (at that time) typically developed using a waterfall-style project. This generally implies that software releases are developed as large chunks taking relatively long time.
• Users do not like their software to change very frequently. The assumption is that they are used to working in a certain way. Ifsoftware changes all the time, the users must regularly adapt how they work, making work less, rather than more, efficient.
• When users do want software to change, they are likely to need to change other aspects of how they work, implying that the deployment of the software must be planned in function of when the users will be ready.
• Testing of software is always partial, because it is too expensive and too time-consuming to try to test all functionality
• The interaction of different components of a software system is difficult to predict
• IT Operations and support do not like software to change frequently. Since software releases generally contain a lot of bugs and because the integration of the software into an operating environment is often not taken into account during the design and testing phases, the work required to iron out the issues is both lengthy and exhausting

The Agile Manifesto was written barely one year after the publication of ITIL Service Support. While agility in software development, and consequently in software releasing, was already being practiced in 2000, the authors of Service Support can surely be excused from taking into account what was not yet recognized as a leading edge in software development trends. The same cannot be said for ITIL 2007. The charitable reader will be perplexed by the failure of ITIL 2011 to better integrate agility into its discussion of release management. Less charitable readers can only regret this failure, which is more probably due to publication policy than to any opinions held by the authors of ITIL 2011.

Agility puts ITIL’s Assumptions into Question

Whatever the rationale, the agile movement questions the well-foundedness of many of ITIL’s assumptions.

• The traditional waterfall approach to managing software development projects has a dismal track record and may be inappropriate in many contexts.
• The assumption that users do not like change is based on changes that are not well aligned to business needs. Changes that truly deliver value are indeed welcome.
• It is not only entirely unacceptable to release software without adequate testing, the design of the test should precede the development of the code! Software must always be in a releasable state.
• Nothing is harder for a developer to fix than a bug introduced months ago, when it is not clear precisely where the bug exists, and frequently when the debugger is a completely different person than the original coder. And nothing is easier for the developer to fix than a bug introduced the same day as it is detected.
• By ensuring that software is always releasable and by radically decreasing the number of bugs, one of the principal objections from operations and support disappears.
• The work of developing software is not finished until that software is delivering value.

Agility Triggers New Questions

All the changes brought on by a more agile approach to software development lead to a new set of assumptions that need to be tested, relative to changing and releasing:

• Software is but one component of an IT service. While this should be the case, many persist in thinking of a release as being a software release.
• The people responsible for operating software inproduction participate in the design and testing of the solutions based on that software. Again, this should be the case. What happens in reality is yet another question.
• Testing includes test cases that may lead to operational acceptance. Even if such tests existed, guess what would be sacrificed first if a release is “late”?

What Agile Developers do not Say

There remain certain circumstances that are not explicitly addressed by proponents of agile software development:

• On many platforms, especially when thick clients are used, the deployment of new software requires a period of unavailability. Depending on the nature of the activities of the users, even short periods of unavailability may be unwelcome and are tolerated only occasionally. It is difficult to imagine a development-driven, continuous deployment approach in such circumstances.
• If new releases provide genuine value to customers, they nonetheless require an investment in time by the people training the users and the people supporting the users. All the time used to update their knowledge and their deliverables is unproductive time relative to their support and training missions. From a lean perspective, these activities are a form of waste.

The Bottom Line

We are probably in a transitional period between systems depending on hard to manage clients and systems with high availability clients. This trend is fostered by the increasing use of software using very thin clients, SaaS, automated and transparent software deployment. We are furthermore in a situation where people who started using computers and software as adults are gradually leaving the business user marketspace. As a result, people accustomed to agile solutions with frequent functional changes will come to dominate the workplace.

The result of these trends is that the technical and social objections very frequent releases will disappear. In this case, all the benefits of frequent releasing will come to dominate the equation, providing higher and more reliable value more frequently.