Spotify Engineering Culture - Part 1

Cultura de Engenharia do Spotify

Parte 1 de 2

Um dos maiores fatores de sucesso aqui no Spotify

é a nossa Cultura de Engenharia Ágil

"Cultura" tende a ser invisível, não a notamos
pois ela está lá o tempo todo,

mais ou menos igual ao ar que respiramos.

Mas, quando todo mundo entende esta Cultura,

há mais chances de mantê-la e até fortalecê-la conforme evoluimos.

E este é o propósito deste vídeo.

Quando o nosso primeiro player de música foi lançado, em 2008,
nós eramos basicamente uma empresa SCRUM.

SCRUM é uma bem estabelecida solução de desenvolvimento ágil

e nos deu uma "Cultura de Time" bem legal.

Porém, alguns anos mais tarde, nós crescemos
com uma boa quantidade de times

e percebemos que algumas das práticas padrão do
SCRUM estavam na verdade atrapalhando.

Então decidimos fazer com que elas fossem opcionais.

"Regras são um bom começo, mas quebre-as quando necessário."

Decidimos que ser ágil importava mais do que o SCRUM e

que princípios ágeis importam mais do que
quaisquer práticas específicas.

Então renomeamos o termo "Scrum Master"
para "Agile Coach" (treinador ágil),

pois queríamos "líderes servidores"
mais do que "mestres em processos".

Também começamos a usar o termo
Squad (pelotão) ao invés de Time SCRUM.

Nosso lema principal se tornou "Autonomia".

Mas, o que seria uma Squad autônoma?

Uma Squad é um Time pequeno, multifuncional e auto-gerenciado.
Normalmente tem menos que 8 pessoas.

Eles trabalham juntos e tem responsabilidade completa
de ponta a ponta para com as coisas que constroem,

Design, "Commit", Entrega, Manutenção,
Operações... enfim, tudo mesmo.

Cada Squad tem uma missão de longo prazo,
como "Fazer do Spotify o melhor lugar para descobrir música".

Ou coisas internas, como "Infraestrutura para testes A/B"
(testes controlados)

"Autonomia" basicamente significa que a Squad decide
o que construir, como construir e como trabalhar juntos para construir.

Existem, claro, alguns limites para isto,
como por exemplo a própria missão da Squad,

a estratégia geral definida para o produto,
seja qual for a área em que estejam trabalhando,

e objetivos de curto prazo, que são
negociados a cada trimestre.

Nosso escritório é otimizado para colaboração.

Aqui está uma típica área de trabalho de uma Squad.

Os membros trabalham juntos aqui, com mesas
ajustáveis e fácil acesso às telas uns dos outros.

Se juntam aqui no salão para coisas
como "planejamentos" e "restrospectivas".

E lá atrás temos uma pequena sala para pequenas
reuniões ou apenas pra ficar tranquilo por algum tempo.

Quase todas as paredes são lousas.

Mas por que autonomia é tão importante?

Bem... porque é motivante! E pessoas
motivadas constroem coisas melhores!

E também, porque autonomia nos deixa mais rápidos,

deixando que decisões aconteçam localmente nas Squads,
ao invés terem que vir de gerentes, comitês e tal.

Ajuda-nos a minimizar "handoffs" e espera,
e então conseguimos escalar o trabalho sem precisar

se preocupar com dependências e coordenação.
Apesar de cada Squad ter sua própria missão,

elas precisam estar alinhadas com estratégias de produtos,
prioridades da empresa e outras Squads.

Basicamente, ser um bom cidadão no ecossistema do Spotify.

A missão geral do Spotify é mais importante
do que qualquer Squad individualmente.

Assim sendo, o princípio chave é
"Ter autonomia, mas não subotimizar".

Mais ou menos como uma banda de Jazz, onde, apesar de
cada músico ser autônomo e tocar seu próprio instrumento,

eles ouvem uns aos outros e focam na música completa como um todo.

É assim que se faz música de qualidade!

Então nosso objetivo é ter Squads
"pouco acopladas mas altamente alinhadas".

Nós ainda não chegamos completamente lá ainda, mas
fazemos várias experiências para tentar chegar cada vez mais perto.

Aliás, isto se aplica a quase tudo neste vídeo.

Esta descrição de Cultura é na verdade uma mistura
do que somos hoje e o que queremos nos tornar no futuro.

"Alinhamento" e "Autonomia" podem parecer dois pontos distantes em uma escala,
do tipo "mais autonomia" é igual à "menos alinhamento".

Porém, nós pensamos nisso mais como
se fossem duas diferentes dimensões.

Aqui embaixo, temos pouca autonomia e pouco alinhamento,
uma cultura de micro-gerenciamento,

sem propósitos elevados, apenas "cale a boca e siga ordens".

Aqui em cima temos bastante alinhamento, mas ainda
pouca autonomia, onde os líderes são bons em dizer

quais os problemas que devem ser solucionados,
("Precisamos atravessar o rio")

mas também estão dizendo COMO eles devem ser solucionados.
("Construa uma ponte!")

Alto alinhamento com bastante autonomia
significa que os líderes se focam

no que deve ser solucionado,
mas deixam os times decidirem como fazer.

E aqui embaixo? Pouco alinhamento e bastante
autonomia significa que os times fazem o que bem entender,

cada um indo em uma direção
diferente, os líderes ficam desamparados

e o produto se transforma em um Frankenstein.
("Espero que alguém esteja trabalhando no problema do rio")

Nós damos duro para tentar ficar aqui em cima.

"Autonomia Alinhada".

E continuamente experimentamos
diferentes maneira de fazer isto.

Então, Alinhamento permite Autonomia.

Quanto mais forte for o nosso alinhamento,
mais autonomia podemos permitir.

Isso significa que o papel do líder é comunicar quais
problemas precisam ser solucionados, e por quê.

E as Squads colaboram entre si
para encontrar a melhor solução.

Uma consequência da autonomia é que
temos muito pouca padronização.

Quando pessoas perguntam coisas como
"Qual editor de código vocês usam?"

ou "Como fazem planejamento?", a reposta é,
na maior parte das vezes, "depende da Squad"

Algumas fazem sprints de SCRUM, outras fazem Kanban,
algumas estimam estórias e medem velocidade, outras não...

Realmente depende de cada Squad.

Ao invés de padrões formalizados, temos
uma forte cultura multi-polinização.

Quando um certo número de Squads usam certa
prática ou ferramenta, como por exemplo "Git",

este se torna o "caminho de menor resistência" e
outras Squads tendem a usar a mesma ferramenta.

As Squads começam a dar suporte àquela ferramenta
e ajudar umas às outras e acaba virando um padrão por si só.

Esta abordagem informal nos dá um
equilíbrio saudável entre consistência e flexibilidade.

Nossa arquitetura é baseada em mais de 100
sistemas separados, codificados e entregues de forma independente.

Há bastante interação, mas cada sistema
se foca em uma necessidade específica,

como "gerenciamento de playlists",
"busca" ou "monitoramento".

Tentamos mantê-los pequenos e
desacoplados, com interfaces claras e protocolos.

Tecnicamente, cada sistema pertence a uma Squad,
na verdade, a maioria das Squads possuem vários,

mas temos um modelo interno open-source,
e nossa cultura é mais voltada para compartilhar do que possuir.

Suponha que esta Squad 1 aqui precisa que algo seja feito no sistema B
e a Squad 2 conheça melhor este código.

Tipicamente, eles vão pedir para a Squad 2 fazê-lo,
porém se a Squad 2 não tiver tempo,

ou tiver outras prioridades, então a Squad 1
não precisa necessariamente esperar.

Detestamos esperar.

Ao invés disso, são bem vindos a editar o código eles
mesmos e pedir para a Squad 2 revisar as alterações.

Então qualquer pessoa pode editar qualquer código,
mas temos uma cultura de revisão de código.

Isto aumenta a qualidade e, principalmente,
espalha conhecimento.

Ao longo do tempo, nós evoluímos
guidelines, padrões de código e outras

coisas para reduzir atritos de engenharia,
mas apenas quando muito necessário.

Então, em uma escala de Autoritarismo para Liberalismo,
definitivamente estamos mais do lado liberal.

Agora, nada disso funcionaria
se não fosse pelas pessoas.

Temos uma cultura realmente
forte de respeito mútuo.

Vivo ouvindo comentários sobre
"Meus colegas são demais!"

As pessoas dão crédito umas às outras o
tempo todo pelo trabalho bem feito

e raramente ficam com o crédito só para si.

Considerando a quantidade de talento
que temos por aqui, há surpreendentemente pouco ego.

Um grande choque para novatos é que ter
autonomia é um pouco assustador no começo.

Você e sua Squad devem encontrar suas próprias soluções.
Ninguém irá lhe dizer o que fazer.

Mas, acontece que, se você pedir
ajuda, você recebe muita, e rápido!

Existe um respeito genuíno pelo fato de que estamos
todos juntos neste barco e precisamos nos ajudar para ter sucesso.

Focamos bastante em motivação.

Aqui um exemplo, um e-mail real
enviado pelo chefe dos "recursos humanos".

"Olá a todos, nossa pesquisa de satisfação diz que
91% das pessoas gosta de trabalhar aqui, e que 4% não."

Isto pode parecer uma taxa alta de satisfação,
especialmente considerando nosso crescimento.

Entre 2006 e 2013, nós dobramos a cada ano,
e atualmente temos mais de 1200 pessoas.

Mas então ele continua:
"Isto, claramente, não é satisfatório, e queremos melhorar."

"Se você for um destes 4%, por favor, entre em contato.
Estamos aqui por vocês, e nada mais."

Portanto, "bom o suficiente"
NÃO é bom o suficiente.

Seis meses depois, já houve melhoras,
e a taxa subiu para 94%.

Com esse forte foco em motivação, não é coincidência
que temos uma super reputação como ambiente de trabalho.

Mesmo assim, temos vários problemas com os
quais lidar, e precisamos continuar melhorando.

Então, temos mais de 50 Squads,
espalhadas entre 4 cidades.

Algum tipo de estrutura é necessário.

Atualmente, as Squads são agrupadas em Tribes.
Uma tribe é uma pequena matriz.

Cada pessoa é membro de uma Squad
e também de um Chapter.

A Squad é a dimensão primária,
focada em entregas e qualidades,

enquanto que um chapter é uma área de competência,
como "QA", "treinamento ágil" ou "desenvovimento web".

Enquanto membro de uma Squad, o meu líder
de chapter é o meu gerente formal,

um líder servidor, focado em me treinar
e ser meu mentor como engenheiro.

Então eu posso mudar de Squads,
sem alterar meu gerente.

É uma bela figura, exceto que,
não é bem assim.

Na realidade, as linhas não são tão
retas e certinhas, e coisas vivem mudando.

Aqui um exemplo, de uma tribe em um determinado período.
E claro, já está tudo diferente hoje.

E tudo bem!
A comunicação mais valiosa acontece por meios informais e imprevisíveis.

Para dar suporte a isto, também temos Guilds.
Uma guild é uma pequena comunidade de interesses,

onde pessoas de toda a empresa se reúnem e
compartilham conhecimento sobre uma área específica.

Por exemplo, "liderança", "desenvolvimento
web" ou "entregas contínuas".

As pessoas podem entrar ou
sair das guilds como quiserem.

As guilds normalmente tem uma lista de e-mails,
conferências bianuais e outros métodos informais de comunicação.

A maioria dos organogramas
organizacionais são uma ilusão.

Portanto, nosso foco principal vai para
"comunidade" ao invés de "estrutura hierárquica".

Descobrimos que uma comunidade forte o
suficiente consegue se dar bem com uma estrutura informal e volátil.

Se você sempre precisa saber exatamente quem
está tomando decisões, você está no lugar errado.

Uma coisa que importa bastante para autonomia:
"quão fácil é colocar nossas coisas em produção?"

Se entregar for difícil, seremos tentados
a entregar menos, para evitar a dor de cabeça.

Isto faz com que cada entrega seja maior, e, portanto, mais difícil.
É um ciclo vicioso.

Mas, se entregar for fácil, podemos entregar continuamente,
fazendo com que as entregas sejam pequenas e, portanto, mais fáceis.

Para ficarmos neste ciclo, e evitar este aqui,
encorajamos entregas pequenas e frequentes.

E investimos pesadamente em AUTOMAÇÃO DE TESTES
e infraestrutura para entregas contínuas.

Entregas deveriam ser rotina,
e não um drama.

Algumas vezes fazemos grandes
investimentos para facilitar as entregas.

Por exemplo, o client desktop original do
Spotify, era uma aplicação única e monolítica.

No começo, com apenas um punhado
de desenvolvedores, isso era aceitável.

Mas, conforme crescemos, se tornou
um grande problema.

Várias Squads tinham que ficar
sincronizadas para cada entrega.

E podia levar meses até chegarmos em uma versão estável.

Ao invés de criar vários processos,
regras e coisas para gerenciar isto tudo,

alteramos nossa arquitetura para
permitir entregas desacopladas.

Usando o framework embutido do Chromium,
o client é agora um WebBrowser disfarçado.

Cada seção é como um frame em um website, e as
Squads podem entregar suas próprias coisas diretamente.

Como parte desta mudança de arquitetura, passamos
a enxergar cada plataforma como se fosse um App.

E evoluímos três tipos diferentes de Squads:
Client App Squads, Feature Squads e Squads de infraestrutura.

Uma Feature Squad se foca em uma
área de funcionalidade, como "busca",

esta squad vai construir, entregar e manter
funcionalidades relacionadas à "busca" em todas plataformas.

Uma Client App Squad, se foca em fazer
com que as entregas sejam fáceis em uma

determinada plataforma,
como desktop, iOS e Android.

As Squads de infraestrutura se focam em fazer
com que as demais squads fiquem mais eficientes.

Elas provêm ferramentas e rotinas para coisas como
"entregas contínuas", "testes A/B", "monitoramento" e "operações".

Independente da estrutura atual, sempre
tentamos aplicar um modelo Self-service,

parecido com um buffet, onde os funcionários não
te servem diretamente, mas permitem com que você se sirva.

Então evitamos "handoffs" (passar de mão em mão)
como se fosse uma praga.

Por exemplo uma squad de
operações ou uma client app squad,

não coloca código em
produção propriamente dito.

Ao invés disso, seu trabalho é
fazer com que fique fácil para

as feature squads colacarem
seus códigos em produção.

Apesar deste modelo, as vezes precisamos de
um pouco de sincronia entre as squads para fazer entregas.

Gerenciamos isto usando "Trens de entrega"
e "Ativação de funções".

Cada App tem seu trem de entrega que parte regularmente,
tipicamente a cada 1 ou 3 semanas, dependendo do client.

Assim como no mundo real, se um trem
parte frequente e confiavelmente,

você não precisa se planejar muito,
apenas apareça e pegue o próximo trem.

Suponha que estas 3 squads estão fazendo
coisas e, quando o trem chega,

as features A, B e C estão prontas,
mas a D ainda está em progresso.

O trem de entrega irá conter todas
as 4 features, mas a que não

está pronta ainda será escondida,
usando um "ativador de função".

Pode parecer estranho entregar features
não concluídas, mas é legal pois

expõe problemas de integração precocemente
e minimiza a necessidade de "branches" no código.

Código isolado (sem commit) esconde
problemas, e é uma forma de débito técnico.

Ativadores de função nos permitem
mostrar e esconder funcionalidades

de forma dinâmica, tanto para
testes quanto em produção.

Adicionalmente, usamos isso para que os testes
A/B possam gradualmente validar as funcionalidades.

No quadro geral, nosso processo de
entrega está melhor do que costumava ser,

mas ainda vemos vários pontos onde melhorar,
portanto continuaremos experimentando.

Isto pode parecer um modelo assustador, deixar cada
squad colocar suas coisas em produção,

sem um controle formal centralizado,
e as vezes cometemos erros,

mas aprendemos que "confiança"
é mais importante que "controle".

Porque contrataríamos
alguém que não confiamos?

Ser ágil em escala, requer
que confiemos em escala.

Isto significa: "sem política",
e também "sem medo",

pois medo não apenas mata a confiança,
mas também mata inovações.

Se uma falha é punida, as pessoas
não se atreverão a fazer coisas novas.

Então, vamos conversar sobre
falhas... na verdade, não..

Vamos fazer um break, levanta um
pouco, pega um café,

deixa você mesmo se acostumar com essa coisa
toda e volte quando estiver pronto para a parte 2, ok?