• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban Software
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

Releases and Changes

1 April 2014 by Robert Falkowitz 2 Comments

“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.

Summary
Article Name
Releases and Changes
Description
Agility puts ITIL's assumptions about releases and changes into question and triggers new questions
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Change management, Release management Tagged With: change management, Continuous Delivery, extreme programming, quality, regression testing, release management, testing

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • Verbs, nouns and kanban board structure
  • The role of the problem manager
  • The Three Indicators

Tag Cloud

service management tools resource liquidity service manager Incident Management bias flow efficiency Cost of Delay incident management tools process metrics process manifesto rigidity problem priority kanban training leadership ITSM knowledge management incident waste service request ITIL agile lean tools process definition kanban board lean management manifesto for software development flow value stream automation context switching knowledge work cause kanban change management histogram impact risk
  • Kanban Software
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2023 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}