Daily Scrum sem propósito é um sinal alerta

A Daily Scrum é o evento mais renegado pelos times Scrum em degradação. Entre as disfunções clássicas do Scrum, esta é provavelmente a mais recorrente, e reconheço que enfrentei este tipo de problema em praticamente todos os times dos quais participei. Posso garantir aos leitores que em algum momento, em todo e qualquer time, irá surgir o comentário: "Precisamos mesmo fazer a Daily hoje? Estou cheio de coisas pra fazer… ". Isso não é bom.

Mas porque este evento é tão importante e porque um alerta deveria ser ligado quando a Daily perde o sentido? A resposta é simples: seu time está abandonando a agilidade, e se transformando aos poucos em um time Waterfall, fazendo Sprints baseadas em tarefas ao invés de metas. Vamos aprofundar isso.

Ao longo deste texto irei usar o termo "Domínio". Entenda que o termo refere-se ao conhecimento necessário para realizar o trabalho em termos de tecnologia e negócio. Em outras palavras, para propor e construir uma solução adequada, precisamos de conhecimento acerca do problema e das ferramentas para construí-la. Chamo isto de "Domínio".

Muita gente pensa que no Scrum não se faz planejamento. Na verdade se faz planejamento diariamente, provavelmente muito mais do que nos métodos tradicionais. A diferença é que no Scrum se faz planejamento do que já é conhecido sobre o produto, durante a Sprint atual, e não antecipadamente, baseando-se em adivinhações. Não se faz previsões ou considerações não validadas, das quais o time ainda não possui Domínio. Desta forma, o risco é sempre limitado a uma Sprint, não ao projeto todo.

Existe uma teoria em relação à evolução do Domínio ao longo do projeto chamado "Cone da Incerteza". Imagine um gráfico de linhas como um cone deitado à direita (>), onde o eixo x representa o tempo e o eixo y a quantidade de dúvidas e incertezas. Com o passar do tempo o time vai conhecendo mais sobre os usuários, recebe feedbacks e aprende mais acerca do Domínio. A redução das incertezas vai dando aos poucos mais precisão às estimativas e mais assertividade às soluções propostas e desenvolvidas.

Então, como fazer planejamento no início do projeto se há tanta incerteza acerca do Domínio? A solução é ter um Product Owner próximo aos usuários e clientes, captando informações importantes que possam subsidiar as decisões de priorização e de construção de soluções, e ao mesmo tempo, criando e realizando estratégias de validação de hipóteses. Estas informações precisam ser compartilhadas com o time no Product Backlog e na Sprint Planning, ou sempre que necessário. Quanto mais informado estiver o PO acerca do Domínio e mais transparente for este conhecimento com o time, mais controle se tem sobre o risco, e mais assertivas serão as hipóteses.

Uma das regras pétreas do Scrum é que cada Sprint deve produzir pelo menos um incremento potencialmente lançável. "Incremento" no Scrum é a soma de tudo que foi feito nas Sprints anteriores mais o que foi feito Sprint atual. Considera-se "Lançável" o incremento que está totalmente de acordo com a definição de Pronto ("Done"), de forma que o PO tem autonomia para decidir quando de fato disponibilizá-lo aos usuários.

Se todo o incremento deve estar 100% pronto e funcional, em tese, não deveriam existir bugs. Mas desenvolver software é uma atividade complexa, e como tal, é natural que surjam erros ou até mesmo ajustes em função dos feedbacks dos usuários e clientes. Com o passar do tempo e mais lançamentos sendo feitos aos usuários, mais bugs e ajustes vão aparecendo. O fluxo natural é que os bugs sejam incluídos no PBL e puxados para as Sprints em concordância do time com o PO para correção. Além disso, com o passar do tempo, é natural que surjam também itens do PBL relacionados a débito técnico, ou seja, correções ou melhorias necessárias no produto em função de simplificações ou erros cometidos deliberadamente pelo time, para que uma ou outra entrega pudesse ser feita mais rapidamente.

Apontei alguns itens nos últimos parágrafos para mostrar que a degradação do projeto é algo natural e previsto ao longo do tempo quando o time não possui um compromisso com a qualidade e com a DoD. Esta degradação vai gerando cada vez mais "itens avulsos" PBL no backlog da sprint, fazendo com que o time fique cada vez mais desengajado e relutante em trabalhar com uma meta de sprint. Em algum momento, a meta da sprint se transforma em algo do tipo "Corrigir todos os bugs" ou "Realizar todas as tasks". Quando este momento chegar, o time perdeu totalmente a conexão com os pilares e valores do Scrum, e provavelmente não será mais capaz de fazer entregas de valor aos clientes até o final da Sprint. Se não ficou claro, considero "itens avulsos" aqueles itens que não entregam valor, ou não fazem parte de algo maior relevante; em outras palavras, é retrabalho e desperdício gerado ou deliberadamente ou por falhas individuais, como já discuti anteriormente.

Quando o time começa a realizar sprints para correção de bugs ou "Hardening Sprints" (que não é exatamente a mesma coisa, mas tem efeitos semelhantes), significa que não há mais foco em metas, mas em tarefas como no bom e velho Waterfall. Neste ponto, a Daily Scrum de 15 minutos não faz mais sentido algum, pois os membros do time têm apenas um conjunto de tarefas a serem realizadas, provavelmente sem nexo algum entre elas. Então, de fato, não há necessidade de se fazer uma reunião diária para alinhar as coisas em direção à meta, pois não há meta para ser alinhada. Este seria um bom momento para considerar o Kanban como uma estratégia complementar e otimizar o fluxo de valor, limitando o WIP. De qualquer forma, entenda que daqui para frente o time matou o Scrum.

Então, como evitar este problema? A solução compreende, na verdade, em um conjunto de atitudes e cuidados, todos voltados a evitar que surjam tarefas avulsas no backlog da sprint e que as sprints possam sempre ser totalmente focadas em metas de valor ao usuário. Coloco aqui algumas alternativas a serem consideradas:

  • Foco na meta da Sprint, e não necessariamente nas tarefas ou itens do backlog.
  • Uma meta de valor ao usuário não é “realizar todas as tarefas da Sprint”; “Implementar a busca com fuzzy matching no e-commerce” é.
  • O time deve usar seu conhecimento e criatividade para construir as soluções e atender aos requisitos dos itens do PBL. Eliminar o máximo de trabalho não necessário é parte disso. Se o PO define o que deve ser feito e como deve ser feito, ele é na verdade um Gerente de Projetos, e não um Product Owner.
  • Coordenar coletivamente o trabalho em equipe com sinergia, otimização e inteligência é o que chamamos de auto-gerenciamento. Ninguém diz ao time como fazer o trabalho, e quais membros do time devem realizar cada tarefa. O time deve ter autonomia e propriedade coletiva sobre a Sprint, sobre seu sucesso e fracasso.
  • O time deve trabalhar em retrospectivas construtivas, levantando pontos de melhoria contínua, buscando constantemente melhorar a definição de "Pronto". Quanto mais rica a definição de “Pronto", melhor será a qualidade do trabalho e menor a insurgência de bugs em produção.
  • Treinamento e evolução constante em testes automatizados de unidade e integração, considerando sempre uma cobertura de teste de código razoável e viável.
  • Recorrer ao débito técnico quando o trade-off é algo realmente relevante e valoroso. O débito técnico deve ser uma decisão transparente e em concordância do time com o PO, visto que a sua correção (ou pagamento) deve ser incluída no PBL.
  • O time deve fazer um monitoramento dos bugs e débito técnico responsável, mantendo-os dentro de padrões aceitáveis e controláveis. Um número que eu costumo usar é limitar as "tasks avulsas" em não mais do que 15% do total de trabalho previsto na Sprint.

Uma Sprint com uma meta bem construída leva a um engajamento maior do time, fazendo com que a Daily Scrum seja fundamental. Práticas pobres de desenvolvimento, falta de testes automatizados, falta de treinamento e transparência, naturalmente gerarão problemas e ineficiência, levando o time a trabalhar como um time "tarefeiro", desengajado e com entregas de valor comprometidas.

Enfim, com este texto procurei mostrar que o abandono da Daily Scrum é um efeito colateral de um time com agilidade moribunda. Quando isso acontecer, provavelmente já passou do tempo do Scrum Master atuar. Procure observar os sintomas que abordei aqui:

  • Aumento do débito técnico
  • Aumento da ocorrência de bugs em produção
  • Daily's monótonas e sem engajamento
  • "Não temos o que melhorar"
  • Tarefas muito detalhadas vindas do PO, sem flexibilidade no desenho na solução.
  • Time desmotivado e estressado
  • PO indisponível

A Daily Scrum é a principal oportunidade de inspeção e adaptação dos desenvolvedores e do time durante a Sprint. O time tem a oportunidade diária de rever sua caminhada em direção à meta, ajustando a caminhada se necessário. Considero que seja o principal evento do Scrum, onde a mágica da confiança, do trabalho em equipe e do auto-gerenciamento emerge. Abandonar a Daily é abandonar a agilidade com Scrum.

Encerro aqui com uma frase famosa: "Não faz sentido contratar pessoas inteligentes e dizer a elas o que fazer; nós contratamos pessoas inteligentes para que elas nos digam o que fazer." (Steve Jobs)

Meu nome é Tiago Luz, sou agilista e desenvolvedor de software na Tolv.

Software developer since 1999, Agilist, entrepreneur and passionate musician. Having fun challenging my limits. Scrum enthusiast. https://www.tiagoluz.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store