• 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 eLearning
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training & Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
    • International Service Management Calendar
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • Subscribe

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

  • 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

  • The Three Indicators
  • Visualization of Configurations
  • How to increase visualization maturity

Tag Cloud

knowledge work kanban board statistical control chart impact Incident Management agility process metrics Service Management urgency bias risk automation incident priority flow adaptive case management process definition service manager rigidity service management tools incident management tools kanban manifesto ITIL change management problem service request Cost of Delay flow efficiency resource liquidity agile value stream waste cause lean management knowledge management context switching manifesto for software development lean change control
  • Kanban eLearning
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

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

This site uses cookies . You accept those cookies when you continue to use this site. Cookie policyAllow cookiesNo 3rd party non-functional cookiesCookie policy
You can revoke your consent any time using the Revoke consent button.Change cookie settings