- Home (Belgium)
- Knowledge Center
- How can you assure a good service experience when dealing with continuous MVP delivery?
How can you assure a good service experience when dealing with continuous MVP delivery?
If you are active in a service management role: How to assure service experience when dealing with continuous MVP delivery?
If you are active in an agile development role: How not to spoil a perfect MVP with poor service?
Agile is hot. Agility needs to be a driver throughout the organization to enable the velocity at which the market wants to consume. In many organizations agile has been used in development for many years, so there is a good understanding of how to ‘be/do agile’. These organizations also learned that the only way to yield the benefits for their customer base is an integrated approach towards agile, involving operations.
This blog identifies and offers an answer to a specific challenge. As this is of interest for both ‘sides’, i.e. developers and operations, the article has two titles. It will be a 3-part blog. Although relevant for everyone, the first part is written from the operations perspective. The second part looks at it from a development perspective. The third part provides the how-to’s and take-aways. Welcome to part one!
Agile Operations: a must-have requirement
The need to be more agile has reached service management, with an increasing demand to ‘make ITSM more agile’. There is guidance everywhere to incorporate agile behaviour into operations. ITIL® 4 says, rightfully so, that we need to check what is available in the organization and re-use it. So why do we not incorporate these agile concepts from development to speed up an agile end-to-end create, deliver and support organization? It would quick-start the agile capability, creating that all-inclusive agile mind-set and way of working. Seems like a no-brainer.
One of the cornerstones of agile in development is that you should work towards deploying minimal viable products (MVP). This allows for quick product delivery, focused feedback and flexibility in product growth, going for that ever-important value realization. Everybody is happy. So why this blog? Well, I discovered a flaw.
Agile Service Operations?
Do we really provide value realization from a service management perspective? There are more aspects to consider than just that newly introduced product, for example:
- Is the service desk aware that the new product is released for the business?
- Is the support organization able to monitor the health of that added product?
- Have the procedures been adapted?
- Is the knowledge pool updated?
- Whom to contact if something goes wrong or is there an Early Life Support in place?
- Which customers will use this functionality?
- Is there a (temporary) need for business priority change?
If any of these questions gets a negative answer or if there are other concerns, you have in fact introduced a service management risk factor: a potential gap that is not under control, resulting in variance of expected service outcome.
Working with that agile MVP approach in service management will not guarantee a good service experience. It guarantees a good product. In ITIL® 4, a typical service is built up of quality product(s) and service actions. It is a wrapper around the provided products to assure the customer experience when engaging with the organization.
Integrating the service dynamics going MVS
This made me think that service management needs its own take on MVP, which I call MVS. So only one letter is different, why the fuss then? Well, it is not about that different letter, the ‘S’. This stands for ‘Service’ as you surely have guessed. It is the ‘MV’, which I think, is a concern.
In an agile context, we know ‘MV’ as ‘Minimal Viable’. According to Wikipedia*, it is a version of a product with just enough features to be usable. In a service management context, ‘MV’ stands for ‘Maximum Viable’. In my opinion, there can never be just ‘a bit of service’. Service management needs to assure that at any point all service components are in harmony, guaranteeing the right provision and support of those products, which continuously enter the operational ecosystem.
It is effective for a service provider to launch a service based on a product with 'minimum viable' functionality, as the market is asking for it. However, the service experience should be always ‘maximum viable’ within the time and budget available. Only this will maximize the benefits of the minimum viable product and a customer perception of quality.
Connecting MVP and MVS
Service experience is a combination of both ‘Minimal Viable Products’ (MVP) and ‘Maximum Viable Services’ (MVS). There should be an equal sense of urgency to introduce the focus on MVS as there is for delivering MVP.
Ask yourself: ‘How should I organize to guarantee that the service experience is maximally tuned for a positive experience? How can I make sure there is no negative impact when consuming that MVP due to a bad service action? Check out the examples in the bullet list mentioned above.’
Watch out for part two of this blog, that looks at this topic from a development perspective.
Want to know more about this topic? Contact us!
(*) Source: https://en.wikipedia.org/wiki/Minimum_viable_product
Principal ITSM Consultant
CTG Belgium Principal ITSM Consultant, Eddy Peters, is a Service Management expert with plus 25 years experience in various IT positions, from support functions to consultancy and from commercial support to managerial positions.
How CTG can help you achieve your desired business outcomes through digital transformation.
Send us a short message by completing the contact form and we’ll respond as soon as possible, or call us directly.
Social media cookies must be enabled to allow sharing over social networks.