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