Spotify: An ITIL® Case Study

Olingo is a Swedish-based management consulting company that works in both the IT service management and agile communities. Most of Olingo’s assignments are focused on striking the right balance between control and agility and finding a relevant level of steering and structure, while also allowing innovation and experimentation, upholding compliance, and maintaining efficiency. Olingo also delivers training services in the form of courses and simulations within the ITIL, DevOps, Management3.0 and Agile methods.

Spotify’s mission is to unlock the potential of human creativity by giving one million artists the opportunity to live off their art, and billions of fans the chance to enjoy and be inspired by these creators.

Spotify is the largest global music streaming subscription service. It is building a two-sided music marketplace for users and artists, which is powered by data, analytics, and software. Spotify provides fans with a way to discover and enjoy music, and artists with an additional avenue to make money and showcase their creative works. For artists, Spotify provides a platform from which they can reach and interact with their fans, as well as analytics which provide a better and more thorough understanding of their fan base.

A key message within Spotify is speed. Making deliveries flow is paramount to maximizing resource utilization. The underlying drive is the need to deliver and improve faster than the competition. In the words of Jack Welch, ‘if the rate of change on the outside exceeds the rate of change inside, the end is near’.

The importance of speed, together with a culture of continuous improvement and autonomy, has a profound impact on the way that processes are designed and improved at Spotify. The focus lies on the purpose and objective of the process rather than on the process activities.

In 2017, the organizational growth at Spotify was massive. Teams that used to work side by side now found themselves scattered around the world. The pending introduction on the American stock exchange introduced new compliance requirements. The organization experienced growth pains, and the need for company-wide policies and common ways of working increased.

Olingo Consulting was contracted to support part of the organization in striking the right balance between control and agility, including the financial systems (FS) support team, which was highly impacted by the regulatory requirements.

The Olingo consultants were brought in to act as agile coaches, and their mission was to gently guide each team by leading them in the right direction. Olingo worked closely with other agile coaches within Spotify on this assignment. There was no project or organizational change programme, and the results were to be reached as part of continuous improvement activities.

The following areas were within the scope of the assignment:

• Managing flow Finding an efficient way to manage the total workload for the teams, including change requests, incidents, technical debt and projects.
• Managing compliance Ensuring that the controls were in place to comply with the regulation imposed by the financial bodies.

At Spotify, work is organized around cross functional, autonomous teams. This means that each team possesses all the capabilities required to drive a piece of work all the way to completion. Hand-offs from one team to another are rare, and avoided wherever possible. Each team is responsible for achieving its mission and reaching its goals but, in return, has the mandate to form a way of working that best fits the team. The FS team is responsible for delivering IT services that are used by internal functions, such as tax, procurement and accounting. When Olingo began working with Spotify, these services were running on an enterprise resource planning (ERP) platform and the FS team was responsible for developing the services as well as improving and supporting them. These services were highly impacted by the compliance requirements imposed by the regulatory bodies. In addition, the FS team had a key challenge at this stage, to move from an on-premise ERP to a mix of various best in class cloud ERPs, in a very limited timeframe. Due to the time constraints, most people involved thought this could not be done in time.

Many other teams at Spotify were impacted by Olingo’s work, but for this case study, only the FS team will be used as an example, and referred to as ‘the team’.

Transparency, visualization and an agile mindset are, together with speed, the driving forces and mantras within the Spotify organization. A key part of the agile mindset is the concept of mission command and autonomous teams. The teams at Spotify were used to getting a clear mission and then, internally within the team, forming the tactics and capabilities to deliver. This mindset had a profound impact on how work was performed and improvements made.

When Olingo began its assignment, ITIL, as a framework, was relatively unknown within the Spotify organization, and some staff members felt that using frameworks slowed them down. However, closer scrutiny proved that very few of the staff members making these remarks had any first-hand experience with ITIL. The ITIL framework served to guide the work being carried out, and implicit references were made to several of the ITIL processes throughout the assignment, including change management, demand management, incident management and request fulfilment.

One challenge for the team was to manage and prioritize the workload in an efficient manner. The team had several customers within the organization, and each of them expected the team to focus on their function’s specific needs. Another challenge was managing the different types of work the team was responsible for performing. Requests for new features from internal customers were mixed with support requests and the need to work on technical debt and strategic projects.

A ticket management tool was in place and being used, but there was difficulty in understanding the order of priority of the tickets logged in the system. The ticket management system was a great place for storing information, but it was not providing great visibility of the total workload. What was needed was a way to visualize the workload so that items could be prioritized, and flow created. However, visualizing the team’s workload was just the first step. In total, four key challenges were identified:

• visualizing the total workload
• managing work overload
• coordinating the needs of internal customers
• managing different types of work.

Visualizing the Total Workload

To get a clear view of the workload, it first had to be lifted out of the ticket management system. The concept of Kanban and a Kanban board was widely spread within Spotify but had not, until then, been used by the team. The work being done by Olingo and their fellow coaches provided a great opportunity to make use of Kanban, in conjunction with ITIL, to track and prioritize different processes carried out by the team. A portable whiteboard was used, and tickets from the ticket management tool printed. The first version was basic, but kicked off discussions and ideas for improvement. The work items were sorted into columns, with each column representing a stage in the workflow, for example ‘to do’ or ‘work in progress’. One challenge that immediately became obvious was the size of the workload. Even if the team had realized that the workload was hidden in the ticket management system, the situation was worse than expected.

Managing Work Overload

To make the workload manageable, work in progress (WIP) limits were introduced for each column. The WIP limits provide an upper boundary on how many work items can be allowed in each column. A limit of three would mean that a maximum of three work items would be allowed at any one time. To ensure that each item had an owner and that individual staff members were not overloaded, so called ‘avatars’ were introduced. An avatar is a representation of a team member, in this case in the form of a whiteboard magnet with the person’s picture on it. For each team member there were two magnets, meaning that a team member could be assigned a maximum of two work items at the same time.

Now that the workload was visualized the next challenge became apparent; how could the work items in the ’To do’ column be managed? This was particularly problematic as most of the work items in this column came from outside of the team.

Coordinating the Needs of Internal Customers

The team had several customers within the organization, each with their own specific needs, requirements and expectations regarding the IT services provided by the team. An advisory board, similar to a change advisory board (CAB) found in ITIL, was needed. However, merely making decisions and planning changes and feature requests would not suffice. Getting input on changes and new feature requests would surely help, but the team would still be left with the challenge of prioritizing its entire workload. This included prioritizing different ITIL processes, such as both incidents and service requests, against change requests.

As a first step, weekly planning meetings were arranged and key stakeholders from each internal customer invited. The visualization of the total workload was an eye opener to all the stakeholders. It was easy for them to see that pushing more work on the team when they were already at full capacity would not move things forward. Just getting the stakeholders together in the same room created a world of difference compared to meeting with them individually. Constructive discussions started and synergies between the stakeholders emerged. Above all, the stakeholders realized that the team had limited capacity and that there was a need to prioritize what was most important for the entire organization, not only for the individual function.

There were still times when everything seemed urgent and of equal importance, but instead of breaking the WIP limit of the ‘to do’ column, the team found another way. They simply left the room and asked the stakeholders to come to an agreement of what work should be prioritised, in line with the ITIL guiding principle of ‘focus on value’. It should not be for the team to decide what is most important from a business perspective.

Managing Different Types of Work

The customer meetings made it possible to choose and prioritize the work items coming from the business. However, there were other types of work items in the team’s total workload and some of them, such as resolving technical debt, were not on the customers’ radar. After some discussion it was agreed that the work items could be divided into four categories:

• support
• enhancements (new features and changes)
• technical debt
• projects

This made the other types of work items visible to the customers but, as the customer saw their enhancement and support requests as more urgent, technical debt and project work still had difficulties reaching the WIP column. The team realized that something had to be done to make those work items that were less urgent, but equally important, flow. The solution was to introduce limits on the different types of work. Even though this created some initial protests from the customers, it proved successful in the long run as the customers started to see the positive impact of removing technical debt and increasing the overall quality of the IT service.

In addition to the weekly planning meetings with the business, the team conducted daily stand-ups to ensure that work was on track and blockers removed. Retrospectives with the objective of improving the ways of working were also performed, both in planned meetings and as daily improvement activities. New things were tested, some of which were kept and others discarded.

Benefits realized included:

• Increased work flow More work items were completed, and lead times shortened.
• Reduced waste More time was spent on the work items that created most value.
• Increased quality More technical debt was resolved, and work on infrastructure projects increased.
• Improved relationships with and between customers The visualization and regular meetings that were set up created synergies and mutual understanding of the needs and situation of each stakeholder involved.

The other part of Olingo’s assignment focused on ensuring that the regulatory controls, imposed and audited by financial bodies due to the stock exchange entry, were adhered to.

The concept of team autonomy had an important role to play in this case. The plan was to introduce generic change, test and release management processes to roll out to all the teams that were impacted by the financial regulation. There were several specific controls to comply with, but the ones that impacted the financial teams the most were the segregation of duty and audit trail requirements. Segregation of duty means that relevant, and separate, roles must be involved in testing and approving changes, and audit trailing means that it must be possible to track all changes made to the financial system.

The processes were drafted, and the team owning the process tool was involved to make the necessary changes to the workflows in the tool. Meetings to go through the processes and planned tool updates with each team and decide how to perform the implementation were arranged. However, instead of getting the acceptance that was expected, Olingo were hit by a flood of questions and comments:

• Why do we need these controls? They seem to slow us down.
• Why should we have a change process that looks like that? We already keep track of all our changes but we work differently to that.
• Why does that role and person need to be involved? They don’t have the time to approve on that level.
• Why are we making that change to the process tool? We use categories in a different way.

Some of the questions and comments could be easily addressed while others proved more difficult to answer. The team autonomy had led to vastly different ways of working and individual ways of using the process tool. The Olingo consultants had made the mistake of acting as teachers instead of coaches and it was clear that they would have to re-think their tactics. They re-grouped and approached the assignment from a different angle, reformulating the message as:

‘These are the regulatory rules you need to comply with. They are a requirement for reaching the organizational goal of stock exchange entry. You need to find a way to comply with these rules. We, together with the internal audit team and the process tool team, are here to help you.’

That message had a completely different effect. The teams listened carefully to the requirements and asked questions to get clarifications. Examples of questions that were raised include:

It was clear that each team had an underlying objective in mind, to comply with the controls while maintaining minimum impact on flow and speed.

The outcome was that each team had its own way to successfully fulfil its requirements, including its own process flows, configuration of the process tool, and way of interacting with key stakeholders. This could have increased some costs and caused some challenges, especially for the auditors, but the drawbacks were overshadowed by the benefits. The flow of work increased, as each team could create a process that fit its own requirements. This, in combination with the benefits of each team taking full responsibility for complying with the controls, and not having the option of blaming a faulty process, created far more value to the organization in the long run.

• Can we set up categories of changes and have different approval flows for them?
• Is it enough to document the reason for the change in the change ticket?
• How can we get approval if a key role is vacant or absent?
• If a change has been approved at an earlier step in the process, does the technical update need approval before being put into production?

The entry on the American stock exchange was successful and the improvement work continues at Spotify. Staff interest in ITIL has increased since the assignment, as the value of the framework has become clear, and recently, Olingo delivered formal ITIL training at Spotify. Although the adoption of ITIL is still ongoing at Spotify, the organization is making great steps towards improving its processes, and already understands and adheres to the ITIL principles better than most companies. They have realized that processes should not be created and obeyed just for the sake of it. The ITIL framework is based on best practice and common sense and Spotify has plenty of that. The processes are there to support the organization in achieving its goals and, as long as the process fulfils its objectives and constraints, there are no rules for its design.

Passionate about striking the right balance between order and chaos, Ola Källgården bends and twists frameworks, models and philosophies into something that is truly useful.

Ola has experience from a range of different roles within the IT world, including developer, business analyst, project manager, organizational change manager and management consultant.

Apart from guiding and coaching clients Ola is also a public speaker as well as an acclaimed and accredited ITIL and DevOps trainer.