itSMFI 2017 Forum Focus - June Forum Focus ITSMFI | Page 15

4.
process that does not act as a roadblock for changes, but
does do the necessary (and only the necessary) checks to
ensure changes can be implemented in the next release. A
Change Advisory Board or similar meeting should be held
frequently enough to provide this flexibility and all
stakeholders need to be present to assess change requests
(including an Operations representative);
Thorough testing of implemented changes before the
release is implemented and business verification after
deployment – if these are not successful (or nobody is avail-
able to do business verification), the changes need to be
rolled back.
In this way, the Change Management process can turn into a
flexible process that helps the company achieve a more dynamic
way of implementing and improving services, thus increasing the
value they provide.
Incremental and Iterative Service Design, Implementation and
Improvement
Contrary to what many Agilists believe, the incremental and
iterative way of working that Agile proposes is not an aim in itself,
which is one of the reasons why introducing practices such as
chopping work up into “iterations” or “sprints” is nothing to do with
being Agile, it is merely doing Agile. The aim of iterative and
incremental development is there to provide value much earlier
in the service development process than with traditional
methodologies (Agile Principles: Our highest priority is to satisfy the
customer through early and continual delivery of valuable
services. Deliver working service enhancements frequently, from a
couple of weeks to a couple of months, with a preference to the
shorter timescale).
grow along with the service complexity once it turns into a fully
virtualised cloud-based Software as a Service (SaaS) offering. A
Capacity Management process may wait being deployed until the
MVS has reached sufficient complexity to require full Capacity
Management.
Note that I see these service development cycles as initially
separate from the Continual Service Improvement (CSI) process:
service development is done to satisfy the agreed initial
requirements for the service. CSI kicks in immediately after the
MVS has gone into production to catch service improvements that
have not been covered by these initial agreed requirements.
However, both cycles will interact with each other in time, and
their respective requirements may well end up in the same service
backlog.
Continual Service Improvement
It hardly needs to be emphasised that CSI is the prime example of
an iterative method to improve services. ISO 20000 primarily bases
improvement efforts on the Deming Cycle (Plan-Do-Check-Act).
Agile has its own version of this cycle (Plan-Develop-Evaluate-
Learn) that comes down to the same principles and refers to it as
“Continuous Improvement” (a subtle difference that is likely only
understood by native speakers and language adepts – I prefer the
word “continual” to the word “continuous” as the latter does not
have the cyclic nature in it that is suggested by the Deming Cycle).
So, methodologies aside, in the context of Service Management, we
want to provide the customer with as much value as possible as
early on in the service provisioning process as possible. Practically,
this means we should adopt the Minimum Viable Service: the most
basic service that still provides value to the customer. Adopting this
concept permit