Estudo de Caso Spotify

Sobre o Spotify
A missão do Spotify é liberar o potencial da criatividade humana,
dando a um milhão de artistas a oportunidade de viver de sua arte, e
bilhões de fãs a chance de curtir e se inspirar com esses criadores.

O Spotify é o maior serviço global de assinatura de streaming de

música. Está posicionado em um mercado de música bilateral para
usuários e artistas, que é alimentado por dados, análises e software.

O Spotify oferece aos fãs uma maneira de descobrir e curtir músicas,

e artistas com um caminho adicional para ganhar dinheiro e mostrar
seus trabalhos criativos.

Para artistas, o Spotify fornece uma plataforma a partir da qual eles

podem alcançar e interagir com seus fãs, bem como oferecer
análises que fornecem uma compreensão melhor e mais completa de
sua base de fãs.

2. Sobre a Olingo Consulting

A Olingo é uma empresa de consultoria de gestão sediada na Suécia
que trabalha tanto na gestão de serviços de TI como nas comunidades
ágeis.

A maioria das atribuições da Olingo é focada em atingir o equilíbrio certo

entre controle e agilidade e encontrar um nível relevante de direção e
estrutura, além de permitir a inovação e a experimentação, manter a
conformidade e manter a eficiência.

A Olingo também oferece serviços de treinamento e simulações nos

métodos ITIL, DevOps, Management3.0 e Agile.

3. Introdução

Uma mensagem chave no Spotify é a velocidade. Fazer o fluxo de

entregas é fundamental para maximizar a utilização de recursos. A
motivação primária é a necessidade de entregar e melhorar mais
rapidamente do que a concorrência. Nas palavras de Jack Welch, "se a
taxa de mudança do lado de fora excede a taxa de mudança do lado de
dentro, o fim está próximo".

A importância da velocidade, juntamente com uma cultura de melhoria

contínua e autonomia, têm um impacto profundo na forma como os
processos são projetados e aprimorados no Spotify. O foco está no
propósito e objetivo do processo e não nas atividades do processo.

4. Background
Em 2017, o crescimento organizacional no Spotify foi enorme. Equipes
que costumavam trabalhar lado a lado agora se encontravam
espalhadas pelo mundo. O ingresso pendente na bolsa de valores
americana introduziu novos requisitos de conformidade.

A organização experimentou dificuldades de crescimento e aumentou a

necessidade de políticas e formas comuns de trabalho em toda a
empresa. A Olingo Consulting foi contratada para apoiar parte da
organização na obtenção do equilíbrio certo entre controle e agilidade,
incluindo a equipe de suporte de sistemas financeiros (FS), que foi
altamente impactada pelos requisitos regulamentares.

Os consultores da Olingo foram contratados para atuar como Agile

Coaches, e sua missão era guiar cada equipe, levando-os na direção
certa. A Olingo trabalhou em colaboração com outros agile coaches
dentro do Spotify nesta tarefa. Não havia projeto ou programa de
mudança organizacional, e os resultados deveriam ser alcançados
como parte das atividades de melhoria contínua.

As seguintes áreas estavam dentro do escopo deste trabalho:

· Gerenciamento de fluxo. Encontrar uma maneira eficiente de

gerenciar a carga de trabalho total das equipes, incluindo solicitações de
mudança, incidentes, dívida técnica e projetos.

· Gerenciamento de conformidade. Assegurar que os controles

estavam em vigor para cumprir a regulamentação imposta pelos órgãos
financeiros.

No Spotify, o trabalho é organizado em equipes funcionais e autônomas.

Isso significa que cada equipe possui todos os recursos necessários

para conduzir um trabalho até a conclusão.
Transferências de uma equipe para outra são raras e evitadas sempre
que possível. Cada equipe é responsável por cumprir sua missão e
atingir suas metas, mas, em contrapartida, tem a responsabilidade de
desenvolver uma maneira de trabalhar que melhor se adapte à equipe.

A equipe de FS é responsável por fornecer serviços de TI que são

usados por funções internas, como aquisições e contabilidade.

Quando a Olingo começou a trabalhar com o Spotify, esses serviços

estavam sendo executados em uma plataforma ERP e a equipe do FS
era responsável pelo desenvolvimento dos serviços, além de
aprimorá-los e apoiá-los.

Esses serviços foram altamente impactados pelos requisitos de

conformidade impostos pelos órgãos reguladores. Além disso, a equipe
da FS teve um desafio fundamental nesse estágio, passar de um ERP
local para um conjunto de vários ERPs de nuvem, em um período de
tempo muito limitado.

Devido às limitações de tempo, a maioria das pessoas envolvidas

achava que isso não poderia ser feito a tempo. Muitas outras equipes do
Spotify foram impactadas pelo trabalho de Olingo, mas para este estudo
de caso, apenas a equipe de FS será usada como exemplo e chamada
de "equipe".

5. A cultura do Spotify e o ITIL

Transparência, visualização e uma mentalidade ágil são, junto com a

velocidade, as forças motrizes e mantras dentro do Spotify.

Uma parte fundamental da mentalidade ágil é o conceito de comando de

missão e equipes autônomas. As equipes do Spotify estavam
acostumadas a ter uma missão clara e, internamente, dentro da equipe,
formando as táticas e capacidades para entregar.

Essa mentalidade teve um profundo impacto sobre como o trabalho foi

realizado e as melhorias feitas.

Quando Olingo começou sua tarefa, o ITIL, como estrutura, era

relativamente desconhecido dentro da organização Spotify, e alguns
membros da equipe sentiram que o uso de frameworks os atrasou.

No entanto, um exame mais detalhado provou que muito poucos

membros da equipe que faziam essas observações tinham alguma
experiência com o ITIL.

A estrutura da ITIL serviu para orientar o trabalho que estava sendo

realizado e referências implícitas foram feitas a vários dos processos da
ITIL durante a atribuição, incluindo gerenciamento de mudanças,
gerenciamento de demanda, gerenciamento de incidentes e
gerenciamento de requisições de serviço.

6. Gerenciando o fluxo

Um desafio para a equipe era gerenciar e priorizar a carga de trabalho

de maneira eficiente. A equipe tinha vários clientes dentro da
organização e cada um deles esperava que a equipe se concentrasse
nas necessidades específicas de suas funções.

Outro desafio foi gerenciar os diferentes tipos de trabalho que a equipe

era responsável por realizar. Solicitações de novos recursos de clientes
internos foram misturadas com solicitações de suporte e a necessidade
de trabalhar em dívida técnica e projetos estratégicos.
Uma ferramenta de gerenciamento de tickets estava em vigor e sendo
usada, mas havia dificuldade em entender a ordem de prioridade dos
tickets registrados no sistema.

O sistema de gerenciamento de tickets era um ótimo local para

armazenar informações, mas não estava fornecendo grande visibilidade
da carga de trabalho total.

O que era necessário era uma maneira de visualizar a carga de trabalho

para que os itens pudessem ser priorizados e o fluxo criado. No entanto,
a visualização da carga de trabalho da equipe foi apenas o primeiro
passo. No total, foram identificados quatro desafios principais:

● Visualizar a carga de trabalho total

● Gerenciar a sobrecarga de trabalho
● Coordenar as necessidades dos clientes internos
● Gerenciar diferentes tipos de trabalho.

6.1 VISUALIZANDO A CARGA TOTAL DE

TRABALHO

Para obter uma visão clara da carga de trabalho, ela primeiro precisou
ser retirada do sistema de gerenciamento de tickets.

O conceito de Kanban e um quadro Kanban foi amplamente difundido

no Spotify, mas até então não havia sido usado pela equipe.

O trabalho que estava sendo realizado por Olingo e seus coaches

proporcionou uma grande oportunidade para usar o Kanban, em
conjunto com o ITIL, para rastrear e priorizar os diferentes processos
realizados pela equipe.

Um quadro branco portátil foi usado e os tickets da ferramenta de

gerenciamento de tickets foram impressos.

A primeira versão foi básica, mas iniciou discussões e ideias para

melhoria.

Os itens de trabalho foram classificados em colunas, com cada coluna

representando um estágio no fluxo de trabalho, por exemplo, "fazer" ou
"trabalho em andamento".

Um desafio que ficou imediatamente óbvio foi o tamanho da carga de

trabalho. Mesmo que a equipe tenha percebido que a carga de trabalho
estava oculta no sistema de gerenciamento de tickets, a situação era
pior do que o esperado.

6.2 GERENCIAMENTO A SOBRECARGA

DE TRABALHO

Para tornar a carga de trabalho gerenciável, foram introduzidos limites

de work in progress (WIP) para cada coluna.

Os limites de WIP fornecem um limite superior em quantos itens de

trabalho podem ser permitidos em cada coluna. Um limite de três
significaria que um máximo de três itens de trabalho seriam permitidos a
qualquer momento.
Para garantir que cada item tivesse um proprietário e que os membros
da equipe não estivessem sobrecarregados, os chamados "avatares"
foram introduzidos.

Um avatar é uma representação de um membro da equipe, neste caso

na forma de um ímã de quadro branco com a foto da pessoa. Para cada
membro da equipe, havia dois ímãs, o que significa que um membro da
equipe poderia receber no máximo dois itens de trabalho ao mesmo
tempo.

Agora que a carga de trabalho foi visualizada, o próximo desafio ficou

aparente; Como os itens de trabalho na coluna "Fazer" podem ser
gerenciados? Isso foi particularmente problemático, já que a maioria dos
itens de trabalho nesta coluna veio de fora da equipe.

6.3 COORDENANDO AS NECESSIDADES

DOS CLIENTES INTERNOS

A equipe tinha vários clientes dentro da organização, cada um com suas

próprias necessidades, exigências e expectativas específicas em
relação aos serviços de TI fornecidos pela equipe.

Um conselho consultivo, semelhante a um conselho consultivo de

mudança (CAB) encontrado no ITIL, era necessário. No entanto,
simplesmente tomar decisões e planejar mudanças e solicitações de
recursos não seria suficiente.
Obter informações sobre mudanças e novas solicitações de recursos
certamente ajudaria, mas a equipe ainda teria o desafio de priorizar toda
a sua carga de trabalho. Isso incluiu a priorização de diferentes
processos ITIL, como incidentes e requisições de serviço, contra
requisições de mudança.

Como primeiro passo, foram organizadas reuniões de planejamento

semanais e os principais interessados de cada cliente interno foram
convidados.

A visualização da carga de trabalho total foi reveladora para todas as

partes interessadas. Foi fácil para eles verem que forçar mais o trabalho
da equipe quando eles já estavam em plena capacidade não levaria as
coisas adiante.

Apenas juntar as partes interessadas na mesma sala criou um mundo

de diferença em comparação ao encontro com eles individualmente.

Começaram discussões construtivas e surgiram sinergias entre as

partes interessadas. Acima de tudo, as partes interessadas perceberam
que a equipe tinha capacidade limitada e que havia a necessidade de
priorizar o que era mais importante para toda a organização, não
apenas para a função individual.

Ainda havia momentos em que tudo parecia urgente e de igual

importância, mas em vez de quebrar o limite de WIP da coluna "fazer", a
equipe encontrou outro caminho. Eles simplesmente saíram da sala e
pediram às partes interessadas que chegassem a um acordo sobre qual
trabalho deveria ser priorizado, de acordo com o princípio orientador da
ITIL de "foco no valor". Não deveria ser da equipe a responsabilidade
por uma decisão do ponto de vista de negócio.
6.4 GERENCIANDO DIFERENTES TIPOS
DE TRABALHO

As reuniões com clientes possibilitaram escolher e priorizar os itens de

trabalho provenientes do negócio. No entanto, haviam outros tipos de
itens de trabalho na carga de trabalho total da equipe, e alguns deles,
como a resolução de dívida técnica, não estavam no radar dos clientes.

Após alguma discussão, foi acordado que os itens de trabalho poderiam

ser divididos em quatro categorias:

● Suporte
● Aprimoramentos (novos recursos e mudanças)
● Dívida técnica
● Projetos

Isso tornou os outros tipos de itens de trabalho visíveis para os clientes,

mas, como o cliente viu suas solicitações de aprimoramento e suporte
como mais urgentes, a dívida técnica e o trabalho do projeto ainda
tinham dificuldades em alcançar a coluna WIP.

A equipe percebeu que algo precisava ser feito para tornar esses itens
de trabalho menos urgentes, mas igualmente importantes, o fluxo.

A solução foi introduzir limites nos diferentes tipos de trabalho. Mesmo

que isso tenha criado alguns protestos iniciais dos clientes, foi
bem-sucedido no longo prazo, à medida que os clientes começaram a
ver o impacto positivo da remoção da dívida técnica e o aumento da
qualidade geral do serviço de TI.
Além das reuniões de planejamento semanais com o negócio, a equipe
realizava levantamentos diários para garantir que o trabalho estivesse
em andamento e os bloqueadores fossem removidos.

Retrospectivas com o objetivo de melhorar as formas de trabalho

também foram realizadas, tanto em reuniões planejadas quanto em
atividades diárias de melhoria. Novas coisas foram testadas, algumas
das quais foram mantidas e outras descartadas.

Benefícios realizados a partir deste trabalho:

● Maior fluxo de trabalho. Mais itens de trabalho foram concluídos

e prazos de entrega reduzidos.
● Redução de desperdício. Mais tempo foi gasto nos itens de
trabalho que criaram mais valor.
● Aumento da qualidade. Mais dívida técnica foi resolvida e o
trabalho em projetos de infraestrutura aumentou.
● Melhoria dos relacionamentos com e entre os clientes. A
visualização e as reuniões regulares que foram criadas criaram
sinergias e compreensão mútua das necessidades e situação de
cada parte interessada envolvida.

7. Gerenciando a conformidade

A outra parte da atribuição da Olingo se concentrou em garantir que os

controles regulatórios, impostos e auditados pelos órgãos financeiros
devido à entrada na bolsa de valores, fossem cumpridos.

O conceito de autonomia de equipe teve um papel importante a

desempenhar neste caso.
O plano era introduzir processos genéricos de gerenciamento de
mudanças, testes e liberações para serem implantados em todas as
equipes que foram impactadas pelo regulamento financeiro.

Havia vários controles específicos a serem cumpridos, mas os que mais

afetaram as equipes financeiras foram a segregação de requisitos de
dever e trilhas de auditoria.

A segregação de funções significa que papéis relevantes e separados

devem estar envolvidos no teste e na aprovação de mudanças, e o
rastreamento de auditoria significa que deve ser possível rastrear todas
as alterações feitas no sistema financeiro.

Os processos foram elaborados e a equipe proprietária da ferramenta

de processo foi envolvida para fazer as alterações necessárias nos
fluxos de trabalho da ferramenta.

Reuniões para percorrer os processos e atualizações de ferramentas

planejadas com cada equipe e decidir como executar a implementação
foram organizadas. No entanto, em vez de obter a aceitação esperada,
a Olingo foi atingida por uma enxurrada de perguntas e comentários:

● Por que precisamos desses controles? Eles parecem nos atrasar.

● Por que devemos ter um processo de mudança que se pareça
com isso? Já controlamos todas as nossas alterações, mas
trabalhamos de maneira diferente.
● Por que esse papel e a pessoa precisam estar envolvidos? Eles
não têm tempo para aprovar nesse nível.
● Por que estamos fazendo essa alteração na ferramenta de
processo? Usamos categorias de uma maneira diferente.

Algumas das perguntas e comentários poderiam ser facilmente

abordados, enquanto outros se mostraram mais difíceis de responder.
A autonomia da equipe levou a maneiras muito diferentes de trabalhar e
a formas individuais de usar a ferramenta de processo.

Os consultores da Olingo cometeram o erro de atuar como professores

em vez de coaches e ficou claro que teriam que repensar suas táticas.
Eles reagruparam e abordaram a tarefa de um ângulo diferente,
reformulando a mensagem como:

"Estas são as regras regulamentares que vocês precisam cumprir. Eles

são um requisito para atingir a meta organizacional de entrada na bolsa
de valores. Vocês precisam encontrar uma maneira de cumprir essas
regras. Nós, juntamente com a equipe de auditoria interna e a equipe de
ferramentas de processo, estamos aqui para ajudá-los."

Essa mensagem teve um efeito completamente diferente. As equipes

ouviram atentamente os requisitos e fizeram perguntas para obter
esclarecimentos. Exemplos de questões que foram levantadas incluem:

● Podemos configurar categorias de mudanças e ter diferentes

fluxos de aprovação para elas?
● É suficiente documentar o motivo da mudança no ticket de
mudança?
● Como podemos obter aprovação se um papel importante é vago
ou ausente?
● Se uma mudança foi aprovada em uma etapa anterior do
processo, a atualização técnica precisa de aprovação antes de ser
colocada em produção?

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.

Ficou claro que cada equipe tinha um objetivo subjacente em mente,

para cumprir os controles, mantendo um impacto mínimo no fluxo e
velocidade.

O resultado foi que cada equipe tinha seu próprio caminho para cumprir
com êxito seus requisitos, incluindo seus próprios fluxos de processos,
configuração da ferramenta de processo e maneira de interagir com os
principais interessados.

Isso poderia ter aumentado alguns custos e causado alguns desafios,

especialmente para os auditores, mas os inconvenientes foram
ofuscados pelos benefícios.

O fluxo de trabalho aumentou, pois cada equipe poderia criar um

processo que atendesse aos seus próprios requisitos. Isso, em
combinação com os benefícios de cada equipe, assumindo total
responsabilidade pelo cumprimento dos controles e não tendo a opção
de culpar um processo defeituoso, criou muito mais valor para a
organização no longo prazo.
8. Resumo

A entrada na bolsa de valores americana e o trabalho de melhoria

contínua foram bem sucedidos no Spotify.

O interesse da equipe sobre ITIL aumentou desde a atribuição, à

medida que o valor da estrutura se tornou claro, e recentemente, a
Olingo forneceu o treinamento formal de ITIL no Spotify.

Embora a adoção do ITIL ainda esteja em andamento no Spotify, a

organização está dando grandes passos para melhorar seus processos,
e já entende e adere aos princípios do ITIL melhor do que a maioria das
empresas.

Eles perceberam que os processos não devem ser criados e

obedecidos apenas por causa disso. A estrutura da ITIL é baseada nas
melhores práticas e bom senso e o Spotify tem muito disso.

Os processos estão lá para apoiar a organização na realização de seus

objetivos e, desde que o processo cumpra seus objetivos e restrições,
não há regras para seu projeto.