Antes de entendermos como escalar o ágil e como a Spotify fez isso, um problema que muitas empresas de tecnologia tentam resolver sem sucesso, gostaria de falar rapidamente sobre porque isso é relevante.
O Spotify é um serviço de streaming de música digital que transformou a forma que nós escutamos música para sempre. Na verdade o Spotify não precisa de muita apresentação, provavelmente você também utiliza o aplicativo criado pela empresa.
Eu já fiz e publiquei anteriormente uma análise completa da cultura do Spotify, caso você não tenha lido ainda, recomendo muito que faça. O motivo?
Tenho visto as empresas simplesmente mudando o nome dos seus times para squads, em alguns casos até implantando uma ou outra ação isolada, mas isso não é nem de perto suficiente para ter um impacto semelhante ao que vemos na Spotify. O sucesso da cultura da Spotify não foi construído em poucos meses, é um trabalho realizado diariamente, promovendo a experiência do colaborador.
Muito trabalho duro diário, principalmente do time de gestão, e um bom tempo foi necessário para conseguir criar uma cultura tão forte. Eu considero um exemplo de como dar autonomia para as equipes de trabalho poderem inovar, por esse motivo ela é a cultura mais copiada por outras empresas, principalmente aqui no Brasil. E além disso, é um dos cases mais interessantes de como escalar o ágil.
Vou entrar em detalhes nesse artigo sobre como escalar o ágil, mas não é uma forma padrão ou um passo a passo para ser seguido, muito pelo contrário. Para ter um entendimento completo espero que você também faça a leitura que sugeri acima, você irá entender por que implantar squads, chapters e guildas na sua empresa não vai melhorar a sua cultura organizacional.
Toda essa forma de trabalho que vamos ver a seguir, e que funciona muito bem, está totalmente amparada por algo muito maior, uma cultura que faz da autonomia seu principal pilar. As práticas e forma de trabalho que muitas empresas copiam do Spotify nunca terão o mesmo impacto quando tiradas do contexto maior, que é composto pela cultura e estratégia da empresa.
Dica: Além da análise da cultura da Spotify, você pode se interessar também por outras duas que fiz, garanto que vale a pena fazer a leitura: Netflix e Airbnb.
Observação: A Spotify (como qualquer boa empresa ágil) está evoluindo rapidamente, vimos isso em detalhes durante a Análise Cultural Spotify. Este artigo é apenas um instantâneo da forma de trabalho – uma jornada em andamento, não uma jornada concluída. No momento em que você lê isso, as coisas provavelmente já mudaram um pouco.
Lidar com várias equipes em uma organização de desenvolvimento de produto é sempre um desafio! E esse é obviamente o principal motivo para querermos entender como escalar o ágil em uma empresa, o seu crescimento. Um dos exemplos mais impressionantes que acompanhei até agora é o Spotify, que manteve uma mentalidade ágil apesar de ter escalado o ágil para mais de 30 equipes em várias cidades.
Alistair Cockburn (um dos fundadores do desenvolvimento ágil de software) visitou o Spotify e disse “Legal –
Tenho procurado alguém para implementar este formato de matriz desde 1992 🙂 por isso é muito bem-vindo. ”
Então, como isso é gerenciado? Vamos ver agora.
A Spotify, assim como a maioria das empresas de software ágil, trabalhava no seu início com o framework Scrum. Conforme a cultura da empresa foi evoluindo o Scrum foi deixado de lado para uma abordagem ágil não mais presa ao framework, possibilitando ainda mais autonomia para seus times.
Cada time (chamado de squad) possui autonomia para definir como vai trabalhar, e todos os squads possuem uma missão, uma estratégia de produto e os seus próprios OKRs, claro, tudo isso alinhado ao restante da empresa.
Como escalar o ágil: o papel dos Squads.
A unidade básica de desenvolvimento no Spotify é o Squad.
Um Squad é semelhante a uma equipe Scrum e é projetado para parecer uma mini startup. Eles se sentam juntos, e eles tem todas as habilidades e ferramentas necessárias para projetar, desenvolver, testar e liberar para produção. Squads são equipes auto organizadas e decidem sua própria maneira de trabalhar – alguns usam Scrum, alguns usam Kanban, alguns usam uma combinação dessas abordagens.
Cada esquadrão (squads) tem uma missão de longo prazo, como construir e melhorar o cliente Android, criar uma experiência de rádio Spotify, escalar os sistemas de back-end ou fornecer soluções de pagamento.
A imagem abaixo ilustra como diferentes squads assumem a responsabilidade por diferentes partes da experiência do usuário.
Essa é uma versão mais antiga do produto da Spotify, mas dá para ter uma ideia de como cada squad fica responsável por uma diferente parte do produto.
Os squads são encorajados a aplicar os princípios de Lean Startup, como MVP (produto mínimo viável) e aprendizagem validada. MVP significa liberar cedo e frequentemente, e aprendizagem validada significa usar métricas e testes A/B para descobrir o que realmente funciona e o que não funciona. O ciclo build-measure-learn (construir-medir-aprender) da Metodologia Lean Startup está resumida no slogan utilizado pelos squads da Spotify “Think it, build it, ship it, tweak it” (Pense, construa, envie, ajuste).
Porque cada squad mantém uma missão e uma parte do produto por muito tempo, eles podem realmente se tornar especialistas nessa área.
A maioria das equipes tem um espaço de trabalho incrível, incluindo uma área de trabalho, uma área de estar e uma sala para relaxar em puffs confortáveis. Quase todas as paredes são quadros brancos, um dos melhores espaços de colaboração que já vi.
Para promover o aprendizado e a inovação, cada squad é incentivado a gastar um perentual de seu tempo com “hack days”. Durante os “dias de hack”, as pessoas fazem experimentos e trabalham em projetos mais pessoais, tentam novas ideias e compartilham com seus colegas. Algumas equipes fazem um hack day a cada duas semanas, outras economizam para uma “semana de hack” inteira. Os hack days não são apenas divertidos, eles também são uma ótima maneira de se manter atualizado com novas ferramentas e técnicas e às vezes levam a inovações de produto importantes!
Um squad não tem um líder formalmente nomeado, mas tem um product owner. O “dono do produto” é responsável por priorizar o trabalho a ser feito pela equipe, mas não está envolvido com a forma como eles fazem o trabalho deles. Os product owners de diferentes squads colaboram entre si para manter um documento de alto nível com o roadmap que mostra para onde o Spotify está se dirigindo, e cada product owner é responsável por manter uma carteira de produtos correspondente para seu squad.
Um squad também conta com um Agile Coach, que o ajuda a evoluir e melhorar sua forma de trabalhar. Os Agile Coachs realizam retrospectivas, reuniões de planejamento de sprint, fazem coaching individual, etc. O ideal é que cada squad seja totalmente autônomo, com contato direto com suas partes interessadas e sem bloqueios e dependências de outros esquadrões.
Basicamente, uma mini startup. Com mais de 30 equipes, isso é um desafio! Para realizar melhorias são realizadas pesquisas trimestrais com cada equipe. Isso ajuda a concentrar os esforços de melhoria e descobrir que tipo de suporte organizacional é necessário.
Aqui está um resumo visual de uma dessas pesquisas, mostrando 5 squads dentro de uma tribo:
Os círculos mostram o estado atual, as setas mostram a tendência. Por exemplo, podemos ver um padrão onde três squads relatam problemas de liberação e que não parece estar melhorando – esta área precisa urgente de foco! Vemos também que os squads 4 e 5 não tem uma ótima relação com o suporte do seu Agile Coach, mas no caso do squad 4 já está melhorando.
● Product Owner – o squad tem um product owner dedicado que prioriza o trabalho e leva em consideração tanto o valor do negócio quanto aspectos tecnológicos.
● Agile Coach – O time tem um Agile Coach que os ajuda a identificar impedimentos e melhorar continuamente seu processo.
● Influência no trabalho – Cada membro do squad pode influenciar seu trabalho, ser uma parte ativa no planejamento e escolha em quais tarefas trabalhar. Cada membro do squad pode gastar 10% do seu tempo em hack days.
● Fácil de lançar – O squad pode (e faz!) liberar suas coisas com o mínimo de complicações e sincronização.
● Processo que se adapta à equipe – A equipe se sente responsável por seu processo e melhora continuamente isto.
● Missão – O time tem uma missão que todos conhecem e se preocupam, e as stories do backlog estão relacionadas à missão.
● Suporte organizacional – O squad sabe a quem recorrer para obter suporte para a solução de problemas, para questões técnicas, bem como questões “leves”.
Como escalar o ágil: o papel das Tribos.
Uma tribo é uma coleção de squads que trabalham em áreas relacionadas – como o reprodutor de música ou a infraestrutura de back-end.
A tribo pode ser vista como a “incubadora” das mini startups (squads), e têm um certo grau de liberdade e
autonomia. Cada tribo tem um líder que é responsável por fornecer o melhor habitat possível para os squads dentro daquela tribo. Os esquadrões de uma tribo estão todos fisicamente no mesmo escritório, normalmente ao lado uns dos outros, e as áreas de lazer próximas promovem a colaboração entre esses squads.
As tribos são dimensionadas com base no conceito do “Número de Dunbar“, que diz que a maioria das pessoas não pode manter um relacionamento social com mais de 100 pessoas ou mais (o número é realmente maior para grupos que estão sob intensa pressão de sobrevivência, o que não é realmente o caso no Spotify, acredite ou não …). Quando grupos ficam muito grandes, começamos a ver mais coisas como regras restritivas, burocracia, política, camadas extras de gestão e outros resíduos.
Portanto, as tribos são projetadas para ter 100 pessoas mais ou menos.
As tribos realizam reuniões regularmente, uma reunião informal onde eles mostram para o resto da tribo (ou quem quer que apareça) em que estão trabalhando, o que entregaram e o que os outros podem aprender com o que eles estão fazendo atualmente. Isso inclui demonstrações ao vivo de software funcional, novas ferramentas e técnicas, projetos de hack day, etc.
Com vários squads, sempre haverá dependências. Dependências não são necessariamente ruins, quando estamos entendendo como escalar o ágil devemos saber que elas irão ocorrer e precisam ser tratadas – os squads às vezes precisam trabalhar juntos para construir algo realmente incrível. No entanto, o objetivo é ter squads que sejam tão autônomos quanto possível, especialmente minimizando dependências que estão bloqueando ou retardando um squad.
Para ajudar nisso, são realizadas conversas regularmente com todos os nossos times para entender de quais outros times eles dependem, e em que medida essas dependências estão bloqueando ou retardando o squad. Aqui está um exemplo:
Em seguida, são discutidas maneiras de eliminar as dependências problemáticas, especialmente bloqueios e dependências entre tribos. Isso muitas vezes leva à repriorização, reorganização, mudanças arquitetônicas ou soluções técnicas.
A pesquisa também ajuda a ver os padrões de como os times dependem uns dos outros – por exemplo, mais e mais squads parecem ser atrasados pelas operações. Um gráfico simples é utilizado para rastrear como os vários tipos de dependências aumentam ou diminuem com o tempo.
Scrum tem uma prática chamada “scrum of scrums”, uma reunião de sincronização onde uma pessoa de cada a equipe se reúne para discutir as dependências. Normalmente não é realizado scrum de scrums no Spotify, principalmente porque a maioria das equipes são bastante independentes e não precisam de tal reunião de coordenação.
Em vez disso, o scrum de scrums acontece “sob demanda”. Por exemplo, quando existe um grande projeto que necessite de trabalho coordenado de vários squads por alguns meses.
Para fazer isso funcionar, as equipes tem uma reunião de sincronização diária, onde identificam e resolvem as dependências entre os squads e usam um quadro com notas adesivas para controlar as dependências não resolvidas.
Quando estamos entendendo como escalar o ágil, uma fonte comum de problemas de dependência em muitas empresas é o desenvolvimento versus operações. A maioria das empresas com as quais trabalho têm algum tipo de transferência (handoff) de desenvolvimento para operações, com atrito associado e atrasos.
No Spotify, há uma equipe de operações separada, mas seu trabalho não é liberar liberar versões para os squads – seu trabalho é dar aos squads o suporte de que precisam para liberar o código por conta própria; suporte na forma de infraestrutura, scripts e rotinas. Eles estão, de certo modo, “construindo o caminho para a produção”.
É uma colaboração informal, mas eficaz, baseada na comunicação face a face ao invés de detalhada
documentação do processo.
Como escalar o ágil: o papel dos capítulos e guildas.
Há uma desvantagem em tudo, e a desvantagem potencial para a autonomia total é uma perda de economias de escala. O testador do squad A pode estar lutando com um problema que o testador do squad B resolveu na semana passada. Se todos os testadores pudessem se reunir, entre squads e tribos, eles poderiam compartilhar conhecimento e criar ferramentas para o benefício de todos os times.
Se cada squad fosse totalmente autônomo e não tivesse comunicação com outros squads, então qual é o sentido de ter uma empresa? O Spotify também pode ser dividido em 30 pequenas empresas diferentes (talvez mais no momento em que você estiver lendo esse conteúdo).
É por isso que a Spotify criou os Capítulos e Guildas. Essa é a cola que mantém a empresa unida, ela fornece algumas economias de escala sem sacrificar muita autonomia.
O capítulo é a sua pequena família de pessoas com habilidades semelhantes, trabalhando dentro da mesma área de competência e dentro da mesma tribo.
Cada capítulo se reúne regularmente para discutir sua área de especialização e seus desafios específicos – por exemplo o capítulo de teste, o capítulo de desenvolvedor web ou o capítulo de backend.
O líder do capítulo é o gerente de linha de seus membros do capítulo, com todas as responsabilidades tradicionais, como desenvolver pessoas, definir salários, etc. No entanto, o líder do capítulo também faz parte de um squad e está envolvido no trabalho do dia a dia, que o ajuda a ficar em contato com a realidade.
Agora, a realidade é sempre mais confusa do que belas fotos como acima. Por exemplo, os membros do capítulo não são uniformemente distribuído pelos squads; algumas equipes têm muitos desenvolvedores web, outras não. Mas a imagem deve dar uma ideia geral.
Uma Guilda é uma “comunidade de interesse” mais orgânica e abrangente, um grupo de pessoas que deseja compartilhar conhecimento, ferramentas, código e práticas. Os capítulos são sempre locais para uma tribo, enquanto uma guilda geralmente corta em toda a organização.
Alguns exemplos são: a guilda de tecnologia web, a guilda de testadores, a guilda de Agile Coach, etc.
Uma guilda geralmente inclui todos os capítulos que trabalham nessa área e seus membros, por exemplo, a guilda de teste inclui todos os testadores em todos os capítulos de teste, mas qualquer pessoa interessada pode ingressar em qualquer guilda.
Cada guilda tem um “coordenador de guilda” que, bem, faz exatamente isso. Como um exemplo de trabalho de guilda, foi realizado uma “Web Guild Unconference”, um evento de espaço aberto onde todos
desenvolvedores web no Spotify se reuniram em Estocolmo para discutir desafios e soluções em seu campo.
Outro exemplo é a guilda de Agile Coaches. Os coaches estão espalhados por toda a organização, mas compartilham conhecimento continuamente e se reúnem regularmente para colaborar na melhoria organizacional de alto nível, devidamente rastreado em um quadro de melhorias.
Espere um segundo, esta não é apenas uma organização de matriz? Sim. Bem, mais ou menos. É um tipo de matriz diferente do que a maioria de nós está acostumado.
Em muitas organizações matriciais, pessoas com habilidades semelhantes são “agrupadas” em departamentos funcionais e “atribuídos” a projetos e “subordinados a” um gerente funcional. A Spotify raramente faz algo assim. A matriz é ponderada para a entrega.
Ou seja, as pessoas são agrupadas em squads estáveis co-localizados, onde pessoas com diferentes conjuntos de habilidades colaboram e se auto organizam para entregar um ótimo produto. Essa é a dimensão vertical na matriz, e é a principal, já que é assim que as pessoas são fisicamente agrupadas e onde passam a maior parte do tempo. A dimensão horizontal é para compartilhar conhecimento, ferramentas e código. O trabalho do líder do capítulo é facilitar e apoiar isso.
Em termos de matriz, pense na dimensão vertical como “o quê” e na dimensão horizontal como “como”. A estrutura de matriz garante que cada membro do squad possa obter orientação sobre “o que construir a seguir”, bem como “como construir bem ”.
Isso corresponde ao modelo de “professor e empresário” recomendado por Mary e Tom Poppendieck. O
PO é o “empreendedor” ou “campeão do produto”, focando na entrega de um ótimo produto, enquanto o líder do capítulo é o “professor” ou “líder por competência”, com foco na excelência técnica.
Existe uma tensão saudável entre essas funções, pois o empreendedor tende a querer acelerar e cortar
cantos, enquanto o professor tende a querer desacelerar e construir as coisas corretamente. Ambos os aspectos são necessários, é por isso que é uma tensão “saudável”.
Como escalar o ágil: o papel da Cultura.
Talvez esse seja o principal erro quando uma empresa pensa em como escalar o ágil, esquecer o papel da cultura organizacional (a base para tudo). Apesar de cada squad ter uma missão, eles precisam estar altamente alinhados, e nesse caso a solução adotada pela Spotify é a mesma que a Netflix utiliza: equipes levemente acopladas e altamente alinhadas.
Como eles mesmos colocam, “como uma banda, cada músico é autônomo e toca o seu instrumento, mas eles escutam uns aos outros e focam na mesma música juntos”.
A autonomia é tão importante pois:
E aqui vai uma dica importante: não caia na armadilha de apenas mudar o nome de times para squads achando que o resultado será o mesmo.
Altamente Alinhados:
Levemente Acoplados:
Como escalar o ágil: o papel da Autonomia.
Alinhamento e autonomia parecem seguir caminhos diferentes, mas vamos ver como a Spotify trata essa situação.
Na verdade o alinhamento é o que permite a autonomia. Apesar de cada squad ter uma missão, eles precisam estar altamente alinhados com a estratégia de produtos e prioridades da empresa. A missão do spotify é o mais importante.
Em vez da padronização, a polinização cruzada. Cada time experimenta novas formas de trabalho e repassa o que aprendeu para outros times, que por sua vez escolhem se vão utilizar também ou não.
Agora vamos analisar as 4 dimensões existentes entre alinhamento e autonomia.
Quadrante 1: Baixo alinhamento e baixa autonomia
Cultura de microgerenciamento, sem propósito maior, colaboradores apenas seguem ordens.
Quadrante 2: Alto alinhamento e baixa autonomia
“Precisamos atravessar o rio, construam uma ponte”.
Líderes são bons em comunicar o que precisa ser feito, mas também dizem o que e como fazer.
Quadrante 3: Baixo alinhamento e alta autonomia
“Espero que alguém esteja trabalhando no problema do rio”.
Times fazem o que querem, cada um vai em uma direção, líderes são inúteis e o produto vira um frankenstein.
Quadrante 4: Alto alinhamento e alta autonomia
“Precisamos atravessar o rio, descubram como”.
Líderes focam no problema a ser resolvido, mas deixam o time identificar como resolvê-lo.
É nesse quadrante que a Spotify se posiciona, o trabalho do líder é comunicar qual problema precisa ser resolvido. E os motivos. O trabalho do squad é colaborar um com o outro para encontrar a melhor solução.
Como escalar o ágil: o papel da arquitetura.
A tecnologia Spotify é altamente orientada para serviços. Existem mais de 100 sistemas distintos, e cada um pode ser mantido e implantado separadamente. Isso inclui serviços de back-end, como gerenciamento de listas de reprodução, pesquisa ou pagamento, e clientes como o player do iPad e componentes específicos como o rádio ou a seção “novidades” do reprodutor de música.
Tecnicamente, qualquer pessoa pode editar qualquer sistema. Uma vez que os squads são efetivamente equipes de recursos e funcionalidades, eles normalmente precisam atualizar vários sistemas para colocar um novo recurso em produção.
O risco com este modelo é que a arquitetura de um sistema seja bagunçada se ninguém se concentrar na
integridade do sistema como um todo. Para mitigar esse risco, temos uma função chamada “Proprietário do Sistema” (System Owner).
Todos os sistemas têm um proprietário de sistema ou um par deles (o emparelhamento é encorajado). Para sistemas operacionalmente críticos, o proprietário do sistema é um par de Dev-Ops par – ou seja, uma pessoa com uma perspectiva de desenvolvedor e uma pessoa com uma perspectiva de operações.
O proprietário do sistema é a pessoa responsável por quaisquer questões técnicas ou arquitetônicas relacionadas a esse sistema. Ele é um coordenador e orienta as pessoas que codificam nesse sistema para garantir que não “tropecem” uns nos outros. Ele se concentra em coisas como qualidade, documentação, dívida técnica, estabilidade, escalabilidade e processo de lançamento.
O proprietário do sistema não é um gargalo ou arquiteto. Ele não tem que tomar pessoalmente todas decisões, ou escrever todo o código, ou fazer todas as versões. Ele é normalmente um membro do squad ou líder do capítulo que tem outras responsabilidades do dia-a-dia, além da propriedade do sistema. No entanto, de vez em quando ele terá um “dia do proprietário do sistema” para fazer o trabalho de limpeza nesse sistema. Normalmente o tempo gasto como proprietário do sistema é mantido na faixa de menos de um décimo do tempo de uma pessoa, mas varia muito entre os sistemas, é claro.
Também existe uma função de arquiteto-chefe, uma pessoa que coordena o trabalho em questões arquitetônicas de alto nível que corta vários sistemas. Ele analisa o desenvolvimento de novos sistemas para garantir que evitem erros, e que eles estão alinhados com a visão arquitetônica. O feedback é sempre apenas sugestões e entrada – a decisão para o design final do sistema ainda recai sobre o time que o constrói.
Como escalar o ágil: o papel do Lean.
A Spotify utiliza a abordagem Lean Startup para desenvolvimento e validação dos seus produtos.
Se você não pode falhar, você não pode aprender. O que separa os MVPs da pesquisa de mercado tradicional é que é uma abordagem de experimentação deliberada baseada no comportamento do cliente, não na opinião.
Precisamos aprender o que os clientes realmente precisam, não o que eles dizem que querem ou o que achamos que eles deveriam querer. Precisamos descobrir se estamos em um caminho que levará ao crescimento de um negócio sustentável.
Com toda essa experimentação, como planejar? Como saber o que será lançado e em qual data?
Inovação é mais importante que a previsibilidade:
Impacto é mais importante que a velocidade:
A cultura da empresa, através dos seus processos e práticas, é criada para ser amigável a erros calculados, permitindo assim que os times realizem testes sem cometer erros graves.
“O erro não pode ser letal, ou não viveremos para errar novamente..”
Ter processos Lean para a Spotify significa manter coisas que estão dando certo e descartar aquelas que estão apenas impedindo, atrasando e criando burocracias desnecessárias.
Como você pode ver, entender como escalar o ágil é só o primeiro passo. Existe muita coisa sendo construída diariamente na cultura da empresa para permitir que os tão copiados squads da Spotify funcionem bem.
O Spotify cresceu muito rápido – em 3 anos, cresceu de 30 para 250 pessoas em tecnologia. Este modelo de escala – com squads, tribos, capítulos e guildas – é algo que foi introduzido gradualmente, então as pessoas se acostumaram com ele. E até agora, com base em pesquisas e retrospectivas, o modelo de escala parece estar funcionando muito bem!
O mais legal é que apesar do rápido crescimento, o engajamento tem aumentado continuamente; No entanto, como acontece com qualquer organização em crescimento, as soluções de hoje geram os problemas de amanhã.
Espero que tenha gostado das dicas e também do conteúdo.
Um grande abraço!
Ajudo você e a sua equipe a melhorar o trabalho e alcançar resultados grandiosos, criando uma cultura de inovação, alta performance e engajamento profissional, porque todos merecem amar o seu trabalho.
