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

collaboration over contract negotiation).
Customer collaboration, however, goes a step further than just
taking feedback to heart. In this case, the customer can play a more
active role in determining the nature and shape of the services that
they are willing to pay for (Agile Principle: Business people and the
service provider must work together daily throughout the service
lifecycle). This has its limits, though: if we are talking about stand-
ard services (e.g. Cloud storage), it may cost a lot to customise them
for one specific customer. Even if the customer is willing to pay for
customisation, this has an impact on the service management
aspects, as likely customised processes to support these services
need to be defined as well. This inevitably reduces the efficiency
and effectiveness of the service management system as a whole.
That said, it should be acknowledged that customers should be able
to influence what a service (even a standard one) should look like:
what existing service elements are deemed unnecessary and what
service elements are to be added in order to provide more value.
Using a Customer Advisory Board or a similar structure to actively
and regularly collaborate with customers on this is a way to achieve
more agility in the design of new and the improvement of existing
services. The “daily” collaboration from the Agile principle may be
has been delivered, the users or customers can make new feature
requests in the form of user stories, which get presented to the
service development team as a prioritised service backlog. The
customer will then be invoiced based on the amount of new func-
tionality that has been added to the service. This does require the
service being contracted in a way that permits fee increases based
on the release of new features as requested through user stories.
Note that the service backlog would also include customer
requirements related to service management aspects: this is again
in line with the outside-in approach to service management
mentioned before. So the customer and users have a say in how
they want the service management processes to function, in
particular the interaction with their own versions of those
processes. Furthermore, specific demands for e.g. reporting and
invoicing may be expressed through a service backlog managed by
the Service Owner. Again, customisation and interaction between
service management processes is only viable if the customer is
large enough to warrant this. That said, smaller customers should
have a say about the effectiveness of service management process-
es and are entitled to an excellent service experience;
perhaps not as tailored as for large customers that pay for it, but
still meeting their expectations.
Focus on People
The ISMF’s core premise is to extend service management with a
people focus. This aspect of Agile is therefore well suited within
the framework that has been described before. Agile has a few
practical focus points that are worth mentioning in this context,
though. These are related to the type of people to hire for a
service-oriented team and the organisation of the team itself.
taken with a grain of salt – the aim is to regularly interact with the
customer to make sure services meet expectations.
This focus on customer collaboration also makes the role of the
Business Relationship Manager (BRM) far more important and
somewhat different. The BRM’s role should be more like that of a
Service Owner on the service provider’s side, which has aspects of
the Product Owner’s role in Agile. In Agile, a Product Owner
represents the business requirements, creates and prioritises a
backlog of user stories, which are basically feature requests for the
product, and interacts with the development side (e.g. with a Scrum
Master) on getting these implemented in the product. In a services
environment, the BRM should be that representative of the
business, providing the customer’s requests for service
enhancements to the service designers and implementers in order
to provide more value.
The Agile Product Owner has the responsibility to work with the
customer to draw up user stories in a specific format, build a
product backlog of user stories and then prioritise the backlog, so
the service development team knows what is most important to
develop. Looking at this from the services perspective, there may or
may not be a case to do this, depending on the nature of the service
and the way in which it has been sold. For large outsourcing deals,
likely the customer cannot be bothered creating user stories and
prioritising them with the Service Owner/BRM. Outsourcing means
delegating that responsibility to a service provider and having it
done by others. Looking at a cloud-based application or platform
(SaaS or PaaS), this structure with a prioritised backlog of user sto-
ries may in fact work better: once the Minimum Viable Service (MVS
– the basic service that provides the core valuable functions of the
service; the Agile terminology is Minimum Viable Product or MVP)
13 itSMFI Forum Focus—June 2017
A Service Management implementation needs to have a focus on
the individual aspects of the people performing their jobs within
the framework. This is to do with a number of aspects of individual
and collective effectiveness. First of all, skills are to be assessed –
not only in the context of job interviews to find the right candidate,
but more so to create a close team of individuals who not only
have their own specialisations, but have a broader development
which gives them the flexibility to deploy their activities in other
areas as well. This permits them to interact more effectively across
functions with other team members. Agile is strongly in favour of
having staff available that can perform multiple roles if required.
Netflix [4] has called these people “T-shaped” to indicate that
combination of a broad background (the horizontal bar of the
letter T) and a deep specialisation (the vertical bar).
As described before, skills and behaviour are directly related to the
right attitude (Agile Principle: Build services around motivated
individuals), especially in an IT environment where (technical)
specialisation often results in a lack of social engagement. Closely-
working teams need people with a cooperative attitude, including
openness to other people’s ideas and perspectives, an active
interest in trying to find new ways to achieve more value; a drive
for innovation and a continual focus on improvement in general, to
name a few things. Paired with the broad-and-deep skills each
team member possesses, this attitude is needed to generate actual
results within the team. Further aspects of attitude that Agile
focuses on include a high level of trust in each other; being able to
take responsibility for one’s results; and a high degree of
adaptability to cope with change in the environment, objectives or
any other aspect.
There is a belief that some Agile proponents propagate, saying that
for teams to be most effective, they should be co-located. At face
value, there is something to say for this, given that it is easier to
communicate with people if you can walk up to them and have a
conversation. However, in today’s virtual workspace, where teams
are more often than not virtual, viz. distributed across multiple
locations, in different time zones and cultures, there simply is no
way to realise this. And I see no real issue with that – today’s
communication tools are so varied that, when set up well, they can