Observando os comportamentos dos times em que passei, vi inúmeros padrões que os impediam de evoluir e se tornarem times mais produtivos. Vários deles usavam Scrum e por isso escolhi as principais armadilhas que tais times estavam caindo e as trouxe aqui para que você não caia também! (Se você está começando agora, sugiro ler esse artigo antes: O que é Scrum?)
Como você deve ler esse texto?
(!) Lembre-se de que tudo que está aqui são armadilhas, ou seja, evite fazer cada itenzinho que eu trouxe aqui, salvo o que eu adicionei #dica na frente. (!)
Planning
O objetivo aqui é alinhar todo mundo ao problema de negócio que vai ser resolvido e que métricas temos potencial de melhorar. Detalhar o que vai ser feito e como vai ser feito.
Quer ajuda para ir além e construir um Roadmap para sua planning? Olha esse artigo sobre como construir um roadmap.
Chegar até aqui sem objetivo da sprint claro
#dica Existem três formas comuns de definir o objetivo da sprint:
1 – O PO chega com uma ideia de objetivo, o time colabora e criamos um objetivo da sprint em conjunto (isso acontece quando o time tem visão de negócio);
2 – O PO chega com um objetivo da sprint e o time só aceita;
3 – O time puxa a lista de itens do backlog e depois escolhe o objetivo, o famoso “alvo ao tiro”.
Ter como objetivo da sprint uma lista de tarefas
#dica O Objetivo precisa ser baseado na entrega de valor para o cliente. O seu time fazendo X, qual é o resultado para o cliente? Esse deveria ser o objetivo.
Ter mais do que 1 objetivo
#dica Se tiver mais que um, que pelo menos sejam priorizados.
O objetivo ser entregar histórias e não valor para o cliente
Ex.: “Terminar a história xyz que dá autonomia para o cliente” em vez de simplesmente “dar mais autonomia para o cliente no ato da compra”.
Pontuar bugs
#dica Normalmente bugs são dívida técnica e precisam ser resolvidos independentemente da pontuação. Além disso, existe uma mudança de comportamento natural no time de abrir mão de qualidade para poder consertar depois, na vibe de “depois pontuamos e puxamos para a sprint”. Até o momento em que o time estará fazendo sprint de resolução de bug.
Exemplo:
1 – O time pontua item como 13 pontos;
2 – Faltando 1 dia para o fim da sprint, o time resolve entregar aquele item com “2 bugs conhecidos”;
3 – No sprint seguinte, o time pontua os bugs como 5 e 3 pontos.
Consequências:
a) O item na verdade “custou” 20 pontos;
b) Como está “tudo bem” e o time “está entregando”, o time não se dá conta que estimou mal e não melhora a estimativa;
c) O time se acostuma a entregar com erros e pontuar os erros depois, falhando na entrega de valor para o cliente;
d) Em última análise, os bugs acabam sendo despriorizados, pois são um item de backlog como qualquer outro, e não dívida técnica;
e) Eventualmente o time acaba se percebendo numa situação desagradável: “sprints de bugs”, “aplicação muito ruim de dar manutenção” etc.
Garantir que o time resolva os bugs independentemente de pontuação faz com o que o time se sinta “penalizado” por ter deixado um bug passar.
Isso reforça um comportamento positivo, que é ter baixíssima tolerância a bugs e efetivamente se responsabilizar pela qualidade – reforce aqui o uso do DoD.
Time só descobrir o backlog na planning
#dica O backlog do PO precisa estar disponível para acesso do time a qualquer momento. Isso permite que o time veja o que vem a seguir e ajude no que for preciso.
Daily
O objetivo aqui é coordenar esforços para o atingimento do objetivo da sprint.
Fazer as 3 perguntas (O que eu fiz ontem? O que vou fazer hoje? Tem algo me impedindo?)
#dica <opiniãopolêmica> Isso leva a um status report de maneira natural. Se eu quero saber o que eu fiz ontem, eu deveria olhar o board. Se eu quero saber o que alguém está fazendo, eu deveria olhar o board. Se tem a alguma coisa me impedindo, eu deveria ter avisado na hora que aconteceu o impedimento, pelo amor de Deus! (“Ahhh mas o meu board está desatualizado” -> Esse é OUTRO problema.)</opiniãopolêmica>
Board só é atualizado na daily
O único momento do dia que o seu board está atualizado é na daily??? Isso quer dizer que em todos os outros momentos de trabalho do dia seu time estará sujeito à descoordenação, retrabalho e falta de visibilidade?
#dica Atualize o seu board o mais próximo possível do tempo real!
Não começar pelo objetivo da sprint
#dica Todos os dias lembrar do objetivo da sprint e dizer se alguém precisa de ajuda para atingi-lo.
Sugiro começar a daily com o Confidence Chart e criar ações para o dia que façam com que seu time fique mais confiante em atingir o objetivo da sprint.
PO dizendo o que o time deve fazer
Isso interfere na auto-organização do time.
#dica Lembre-se que o time de desenvolvimento é auto-organizado.
(Sugestão de texto: relembre o papel do PO.)
SM dizendo o que o time deve fazer
Isso interfere na auto-organização do time.
(Sugestão de texto: relembre o papel do SM.)
Daily sendo feita para o PO
Vira status report e reforça hierarquia (que não deve existir entre PO e time).
Daily sendo feita para o SM
Vira status report e reforça hierarquia (que não deve existir entre SM e time).
Review
O objetivo aqui é colher feedback sobre a evolução do produto ou serviço e saber se estamos indo no caminho certo.
Não ter cliente final (pessoa que vai usar o produto/serviço) na review
#dica Gosto muito de usar a comparação com código em produção. Nosso objetivo é ter o código em produção, não em homologação, não no ambiente de desenvolvimento, não na máquina local.
O mesmo raciocínio funciona para review e receber feedbacks. Primeiro do cliente final (produção), não dos stakeholders e gestão (homologação), não dos outros times (desenvolvimento), não do PO (máquina local).
Disclaimer alert!!! Review para PO é o pior cenário possível #nãorecomendo, pelo mesmo motivo de ter código só na sua máquina. Se o PO espera a review para saber o que está acontecendo, ele não está fazendo o trabalho direito.
PO não anotar feedbacks
#dica PO, lembre-se: esse é o objetivo dessa cerimônia.
PO não trazer o objetivo da sprint e estratégia
Não deixar o time de desenvolvimento mostrar o que construiu
#dica O time precisa mostrar o que eles fizeram, isso aumenta o engajamento e a vontade de pertencer.
Retrospectiva
O objetivo aqui é ver onde podemos melhorar como um time de forma geral.
Não fazer retrospectiva “porque não temos tempo”
Fazer retrospectiva depois da planning
Parece óbvio, né? Mas já me deparei com muitos times fazendo retrospectiva depois da Planning.
#dica Já aplicar na planning as melhorias da última sprint, e isso só acontece se você fizer a retrospectiva antes.
Não ter planos de ação / Ter muitos planos de ação
Por favor foque em alguns, os que doem mais.
#dica Se esses planos de ação forem itens que você faz uma vez e pronto, sucesso, ok. Entretanto, se forem itens que você precisa repetir para sempre, cogite colocá-los no acordo de times. Por favor, tenha um acordo de times!
Repetir a mesma retrospectiva sempre
Não ter um objetivo claro com a retrospectiva
#dica SMs do meu coração, vocês precisam construir ou rodar uma retrospectiva com foco em qual problema do time vocês querem resolver. O “como” fica com o time.
A retro é a planning do SM. Na planning o PO chega com o problema do produto/serviço que o time vai resolver, o time traz o como.
Na retrospectiva, o SM traz o problema que ele quer resolver do time em forma de dinâmica (você não precisa deixar explícito o problema, deixe que sua dinâmica fale por você) e o time traz o como.
Não atualizar a Definição de Preparado (DoR)
#dica Use a pergunta “O que deveria estar claro antes, que não estava e permitiria que tivéssemos feito a entrega?”. Uma resposta pode ser, por exemplo: “Ahhh, se soubéssemos que tabelas acessar antes, não teríamos perdido tanto tempo nisso e teríamos conseguido entregar”. Ótimo, novo item no DoR -> Tabelas que vamos acessar explícitas.
Refinamento
O objetivo é levantar problemas, necessidades, oportunidades e métricas, assim como deixar os itens preparados para o time.
<opiniãopolêmica> Isso já deveria ser um evento oficial. </opiniãopolêmica>
Negócio
Não ter clientes e stakeholders
Não ter claro o problema que vamos resolver
PO estar no refinamento de negócio sozinho
#dica Sim, alguém do time de desenvolvimento deveria estar aqui junto entendendo o negócio.
Refinar extensivamente até os últimos e micro detalhes
Não ter uma métrica de negócio atrelada ao item de backlog
#dica De forma geral o refinamento de negócio permite o PO e o time entenderem melhor a demanda antes de criá-la. Além de alinhar expectativas de clientes, stakeholders e time de desenvolvimento.
Técnico
Não olhar o DoR
Não ter planos de ação sobre as dependências que vão surgir
Fazer só com a mesma pessoa sempre
Queremos que todo mundo do time se envolva com as dependências técnicas e como resolve-las. O ideia aqui é evitar a alta dependência do conhecimento técnico de 1 ou 2 membros do time.
#dica O refinamento técnico possibilita o time mitigar riscos e dependências antes da sprint. Deixar para a planning será tarde demais, o time não terá tempo hábil para resolver os impedimentos. Ter um bom DoR e olhar para ele no refinamento técnico ajuda a deixar o trabalho mais fluido durante a sprint.
DoD
O objetivo aqui é garantir qualidade.
Lista superficial demais
#dica Tentem deixar o mais explícito possível. Ex.: Em vez de “Segurança da informação OK”, tente “Lista do OWASP top 10 cobertos”.
Não levar em consideração o cenário do time
Ser top-down
Entendo que em vários cenários a organização tem necessidades de regras e compliances, e tudo bem elas serem transmitidas para os times via DoD, mas elas não podem ser as únicas.
#dica O time precisa colocar os itens que eles acreditam fazer sentido para a garantia da qualidade no contexto deles.
Ignorar o DoD ao mover para o status Done
Não atualizar
DoR
O objetivo aqui é mitigar riscos da sprint.
Lista superficial demais
#dica Tem que ser específico, evite coisas do tipo “todo o time entendeu a história”. Entendeu mesmo? Será? Ou no meio da sprint vão surgir várias dúvidas? Use coisas do tipo “Campos que serão usados, mapeados”, “Precisa criar API, sim ou não” e diversas outras coisas específicas do seu dia a dia.
Não usá-la no refinamento técnico
Não atualizar o DoR na retrospectiva quando necessário
Ser radical demais com os itens na lista
#dica Lembre que os itens nessa lista são trade-offs explícitos sobre o risco. Se o item que vocês estão abrindo mão pode gerar um risco baixo para a sprint, talvez tudo bem não o seguir.
Faltou alguma coisa importante aí? Comenta aqui embaixo e vamos trocar ideia!
