O que é o "Squad Health Check Model" do Spotify?

Muitas empresas experimentam diferentes possibilidades para avaliar e visualizar onde suas equipes estão. Normalmente, isso acontece com a ajuda dos chamados Maturity Models, ou seja, modelos de maturidade, que representam uma evolução através de diferentes níveis.

As intenções por trás desses modelos são geralmente positivas – por exemplo, quando gestores, líderes ou coaches em organizações maiores querem ter uma noção melhor de onde deveria estar o seu foco em relação a melhorias e problemas, ou quando querem ajudar suas equipes a se tornarem mais reflexivas, para que elas também possam se concentrar melhor nas suas próprias melhorias.

No entanto, preferimos chamar de "Health Check Model" (modelo de verificação de saúde) em vez de "Maturity Model", já que este último... bem... soa um pouco paternalista. Além disso, a maioria dos nossos modelos não contempla a evolução através de diferentes níveis. O público-alvo principal é a própria equipe e não a gestão.

A melhoria da organização muitas vezes se assemelha a um jogo de adivinhação (como saber o que precisa ser melhorado? E como saber se algo melhorou?). Uma abordagem sistêmica com uma visualização clara pode reduzir esse jogo de adivinhação ao mínimo.

Ok, mas esses modelos realmente funcionam?

Depende. Em alguns casos, esses modelos podem ser realmente úteis. Às vezes é mais "meh" – as pessoas cumprem sua obrigação e participam de workshops, pesquisas etc., mas os dados gerados são ignorados.

Mas tenha cuidado. Já vimos como esses modelos se transformaram em verdadeiros monstros em algumas empresas; uma ferramenta sistêmica de opressão que gera subotimização e medo. Os gestores usam o modelo de maturidade para avaliar e colocar equipes umas contra as outras, e as equipes escondem seus problemas para parecerem bem. E isso não é nada bom!

Embora o dano potencial seja mais provável do que o benefício potencial, EXISTE um benefício potencial e há maneiras de evitar um desastre.

No Spotify experimentei isso por alguns anos e encontrei abordagens que funcionam bem (ou seja, têm mais vantagens do que desvantagens) – no melhor caso são "úteis", no pior caso "meh" e até agora nunca foram um "desastre". Também implementamos esse Health Check Model em algumas outras empresas e obtivemos resultados semelhantes, então achei que era hora de escrever um artigo sobre isso.

Para quem é destinado o Health Check Model?

No modelo de Health Check de um Squad (nosso termo para uma pequena equipe de desenvolvimento interdisciplinar e auto-organizada), existem principalmente dois stakeholders:

• 1) O próprio Squad

  Ao discutir os indicadores individuais, os membros do Squad conseguem entender melhor o que funciona para eles e o que não funciona. A ampla variedade de perguntas ajuda a expandir seus horizontes. Talvez eles estejam cientes dos problemas de qualidade do código, mas não tenham realmente pensado no valor do ponto de vista do cliente ou em quão rapidamente conseguem aprender. Além disso, tanto os pontos positivos quanto os negativos são destacados.

• 2) Pessoas que apoiam o Squad.

  Gestores e coaches que trabalham fora da equipe (ou pelo menos parcialmente fora da equipe) obtêm uma visão geral de tudo o que funciona e o que não funciona. Além disso, conseguem identificar padrões entre diferentes Squads. Quando você tem dezenas de equipes e não consegue conversar com todas sobre tudo, esse tipo de resumo pode ajudar a descobrir como usar melhor seu tempo e com quem falar sobre o quê.

Estar consciente do problema é o primeiro passo para resolvê-lo. Esse tipo de visualização torna muito mais difícil ignorar um problema.

Como fazemos isso no Spotify

Principalmente fazemos três coisas:

1. Realizamos workshops nos quais os membros de um squad discutem e avaliam sua situação atual com base em diversos aspectos (por exemplo, qualidade, diversão, valor, etc.)

2. Criamos um resumo gráfico do resultado

3. Ajudamos os squads a melhorar

Temos diferentes variantes. Uma chamamos simplesmente de "Squad Health Check Model", outras se chamam, por exemplo, "Fluent@Agile-Spiel" ou "Quarterly Reflection". O "Health Check Model" é uma versão melhorada da pesquisa trimestral "Autonomous Squads", que foi mencionada em 2012 no artigo Scaling Agile @ Spotify.

Aqui está um exemplo real do Health Check Model de uma "Tribe":

Aqui está representado como 7 Squads diferentes avaliam sua própria situação. As cores mostram como está atualmente (verde=bom, amarelo=alguns problemas, vermelho=muito ruim). As setas indicam a tendência (está melhorando ou piorando?).

Se você observar o diagrama com atenção por alguns minutos, vai perceber algumas coisas interessantes:

• Nas colunas você pode identificar as principais diferenças entre os diversos Squads. O Squad 4 está satisfeito com praticamente tudo. O Squad 2 tem muitos problemas, porém há uma tendência positiva em quase todos os pontos.

• Nas linhas você pode identificar padrões sistêmicos. Todos os Squads se divertem no trabalho (e a tendência continua subindo!). Motivação aparentemente não é um problema. No entanto, o processo de release está causando problemas e a base de código também não parece muito boa. Com o tempo, isso certamente vai impactar também o fator diversão no trabalho.

• No panorama geral você pode ver que quase todas as setas apontam para cima, em todo o diagrama há apenas 2 setas para baixo. Isso significa que o processo de melhoria (o processo mais importante de todos) aparentemente está funcionando.

Isso é, claro, apenas uma representação aproximada da realidade ("Todos os modelos estão errados, mas alguns são úteis." – George Box). Por isso, é uma boa ideia verificar tudo novamente antes de tomar medidas concretas.

Será que na Squad 4 está realmente tudo tão bem ou eles são apenas otimistas e não veem seus problemas? A maioria das squads acha que entrega valor aos seus clientes – mas como sabem disso? Essa afirmação é baseada em wishful thinking ou em feedback real dos clientes?

A Squad 4 do nosso exemplo foi, na verdade, formada apenas uma semana antes do Health Check ser realizado. Portanto, eles definitivamente ainda estavam na fase de orientação (também chamada de fase de Forming ou fase de lua de mel). Por esse motivo, tanto a Squad 2 quanto a Squad 4 precisaram de muito apoio.

A facilidade de entrega era um grande problema aqui. Então, o foco passou a ser mais em coisas como Continuous Delivery (entrega contínua) e logo foi possível perceber uma melhoria significativa.

Por favor, lembre-se de que este é um modelo de autoavaliação; baseado na honestidade e na opinião subjetiva dos membros da squad. Portanto, só funciona em um ambiente de confiança, onde as pessoas podem ter certeza de que seus gestores e colegas agem no interesse delas. Coletar os dados é bastante simples – então trata-se principalmente de que não deveria haver motivos concretos para não fazer isso.

Felizmente, no Spotify existe um ambiente de confiança assim, e os gestores e coaches fazem questão de transmitir que esta é uma ferramenta de apoio e não de avaliação das squads.

Como coletamos os dados

Descobrimos que pesquisas online para esse tipo de propósito são uma porcaria total. Isso acontece principalmente porque elas não permitem conversas, e essa é justamente a parte mais valiosa. Enquanto os membros do Squad conversam, você obtém insights adicionais, e o coach descobre como pode ajudar os Squads de forma eficaz. Os dados sozinhos mostram apenas uma pequena parte do panorama geral, o que pode ser enganoso.

Por isso, nós (geralmente agile coaches) organizamos workshops com os Squads e incentivamos conversas diretas sobre os diferentes indicadores do "Health Check Model". Uma a duas horas costumam ser suficientes para isso.

Para a facilitação, usamos um conjunto chamado "Awesome Cards". Cada carta representa um dos indicadores e contém tanto um "Example of Awesome" (exemplo de algo excelente) quanto um "Example of Crappy" (exemplo de algo que está ruim).

Um set normalmente consiste em cerca de 10 cartas. Aqui está o exemplo de um set completo:

Em cada pergunta, os Squads são questionados se se veem mais perto de "Awesome" ou "Crappy". Para facilitar a concordância sobre uma cor para os indicadores e a respectiva tendência (estável, tendência de alta/baixa), usamos métodos básicos de workshop como, por exemplo, Dot Voting.

Aqui estão os cartões como download em PDF

Mantemos tudo bem simples com três níveis (verde/amarelo/vermelho). A definição exata da codificação de cores pode variar, mas baseia-se nas seguintes afirmações:

Verde não significa necessariamente que tudo está perfeito. Significa apenas que o Squad está satisfeito e no momento não vê grande necessidade de melhorias.

Amarelo significa que existem alguns problemas que deveriam ser resolvidos, mas não são um desastre.

Vermelho significa que algo está realmente dando errado e precisa ser melhorado.

Sim, esses são dados subjetivos. Teoricamente, cada Squad tem liberdade para incluir também dados objetivos (tempo de ciclo, número de defeitos, velocidade etc.). No entanto, muito poucos fazem isso. Isso acontece porque os Squads também precisam interpretar dados objetivos e decidir se eles significam que há um problema ou não. No final das contas, tudo é subjetivo de qualquer forma. Se algo parece um problema, então é um problema.

Às vezes combinamos isso com Retrospectivas, por exemplo, escolhendo um cartão e depois pensando em ações de melhoria para ele.

Quais perguntas você deveria fazer?

Se você observar os exemplos mencionados acima, perceberá que as perguntas nem sempre são as mesmas. Este é um bom guia:

• As perguntas devem cobrir uma ampla variedade de perspectivas diferentes.

• Essas perguntas são apenas um ponto de partida, uma pré-seleção exemplar. Os Squads podem decidir livremente se querem remover, adicionar ou modificar perguntas, se acreditarem que isso faz sentido.

• Tente limitar o número de perguntas a aproximadamente 10 perguntas. Com mais perguntas, podem ocorrer sobreposições rapidamente, por isso elas podem ser removidas.

Deve-se prestar atenção para que as perguntas se refiram ao ambiente em que um Squad trabalha, e não a dados concretos (como a Velocity). Isso torna tudo menos ameaçador e reforça mais uma vez que se trata de apoio e melhoria – e não de avaliação.

Nossa suposição (seja verdadeira ou não) é que um Squad tem uma motivação intrínseca para ser bem-sucedido e entregar o melhor desempenho possível nas circunstâncias dadas.

Com que frequência medimos a saúde dos Squads?

Como mencionamos, recorremos a diferentes modelos, por isso isso varia bastante. Ainda não encontramos um "intervalo de tempo perfeito" para esse tipo de coisa (e provavelmente nunca encontraremos).

Trimestralmente parece ser um bom ponto de partida. Mensalmente é provavelmente um pouco frequente demais (as pessoas rapidamente acham cansativo e os dados não mudam rápido o suficiente). Semestralmente parece ser pouco frequente (em meio ano podem acontecer muitas coisas). Mas como dissemos, isso sempre varia.

Conclusão – O que você deve considerar se quiser experimentar isso

Um modelo assim PODE ajudar a impulsionar melhorias. Mas também pode virar toda uma cultura empresarial de cabeça para baixo se não for feito corretamente! Por isso, deve-se sempre proceder com cautela.

Aqui estão algumas diretrizes que aumentam a probabilidade de sucesso:

• Tenha clareza sobre os motivos para a introdução do modelo. Deve sempre ser sobre melhoria, não sobre avaliação.

• Você deve coletar os dados principalmente através de comunicação pessoal, não por pesquisas online. Este processo deve ser interessante e divertido.

• Envolva as equipes na aplicação do modelo e permita que façam adaptações conforme suas necessidades.

• A aceitação da equipe é mais importante que a consistência dos dados. Se a Equipe A escolhe um conjunto de perguntas um pouco diferente da Equipe B, tudo bem (mesmo que o resumo fique um pouco mais confuso).

• Certifique-se de que não haja incentivo para trapacear. Não deve haver motivos para uma equipe querer parecer melhor do que realmente é.

• Encontre uma forma simples de visualizar os dados. Quanto mais óbvia e intuitiva for a visualização, maior a probabilidade de ser utilizada.

• Tente não comparar as equipes entre si. Se a Equipe A avalia os pontos principalmente com verde e a Equipe B em grande parte com vermelho, isso não significa automaticamente que a Equipe A é "melhor". Pode significar igualmente que a Equipe A tem um contexto mais simples, é mais otimista, ou que a Equipe B é mais honesta sobre as dificuldades. Seja qual for o motivo, significa simplesmente que a Equipe B precisa de um pouco mais de apoio. A postura do gestor deve ser "Como posso ajudar?" e não "Por que vocês são tão piores que os outros?".

• Faça um acompanhamento. Faça perguntas como: "Este modelo está ajudando vocês?", "Se parássemos de fazer Health Checks, vocês sentiriam falta?" ou "Como poderíamos tornar este modelo ainda mais útil?". O modelo (e a forma como você o aplica) precisa ser continuamente melhorado.