Quais são as duas coisas que o Time Scrum deve fazer durante o primeiro Sprint?

Toda equipe Scrum quer ser incrível e atingir todas as metas do Sprint. Continue lendo para obter o conselho de um Scrum Master sobre como alcançar a grandiosidade.

Recentemente me perguntaram sobre a composição de uma equipe Scrum de alto desempenho.

Por que algumas equipes Scrum consistentemente cumprem seus compromissos de sprint – independentemente da dificuldade do trabalho e parecem não ter limite para sua capacidade de aumento de velocidade – enquanto outras equipes lutam e parecem perder mais compromissos de sprint do que fazem?

Devo admitir que em uma grande organização global, mesmo entre equipes maduras, vejo graus muito variados de sucesso em nossas equipes Scrum.

Sabemos que uma equipe Scrum pode enfrentar desafios técnicos difíceis, porém sua natureza auto-organizada possibilita a criação de um ambiente com conversas ricas guiadas por um pensamento inovador coletivo.

Li recentemente que a diversidade da equipe melhora as decisões. Seria esse um fator que contribui para uma equipe Scrum de alto desempenho? Mas primeiro, vamos definir uma equipe saudável.

Uma equipe Scrum saudável entrega uma quantidade de trabalho acordada, ao mesmo tempo em que impõe um padrão de cuidado.

O trabalho é definido pelo Product Owner e tem valor para os stakeholders.

A responsabilidade perante as partes interessadas é primordial, mas é superada pela responsabilidade perante o coletivo da equipe.

A equipe é um “grupo pequeno, co-localizado, auto-organizado, auto-contido, orientado a valor, de membros da equipe em tempo integral que são organizados em torno de uma missão. Seu trabalho é produzir resultados de alta qualidade em um ritmo sustentável.” (Equipe Scrum, ScrumDictionary.com. Fevereiro de 2018)

Muitas vezes observei que, embora muitas equipes atendam à definição acima de uma equipe saudável, uma equipe de alto desempenho tem algo a mais. São pensadores inovadores.

As equipes que cumprem e excedem continuamente seus compromissos de sprint estão resolvendo problemas difíceis e eliminando barreiras. Essas equipes se tornam proficientes em colaboração e pensamento criativo.

Um estudo psicológico de 2003 da Stanford Graduate School of Business sobre tomada de decisão em grupo encontrou uma forte correlação entre diversidade e solução inovadora de problemas.

Os alunos foram formados em equipes e solicitados a colaborar para resolver um complicado assassinato real.

Havia dois grupos de estudo. O primeiro grupo de estudo foram equipes de quatro amigos. O segundo grupo de estudo eram equipes de três amigos e um estranho.

Eles receberam fatos conhecidos idênticos sobre o assassinato e a mesma lista de suspeitos.

O verdadeiro assassino era conhecido apenas por aqueles que conduziram o estudo.

As equipes que incluíam um estranho consistentemente fizeram um trabalho melhor em encontrar o assassino correto.

A surpresa para o estudo foi que o estranho não apenas representava um conjunto diferente de valores e diversidade de pensamento, mas proporcionou a introdução de um possível desafio ao julgamento unânime o que levou os amigos a revisitar suposições e refazer seus pensamentos antes de chegar a uma conclusão.

Além disso, eles “prestavam mais atenção ao recém-chegado e às tarefas em mãos e estavam mais dispostos a mudar seus pontos de vista”. Em suma, “o estranho provocava os amigos a aumentarem o jogo”. (Tim Harford, 2016)

Outro estudo realizado por Solomon Asch em 1951 descobriu que as pessoas às vezes “suprimem suas próprias opiniões para concordar com um grupo unânime”.

A pressão do pensamento de grupo era muitas vezes capaz de fazer o participante do estudo escolher o que estava claramente errado.

No entanto, uma única voz discordante foi suficiente para dar ao participante a liberdade de pensar de forma independente e escolher o que sabia ser correto.

Equipes de colegas com ideias semelhantes estão sujeitas ao pensamento de grupo e ficam presas.

“Adicionar uma nova perspectiva ou um novo conjunto de habilidades pode desencorajar a equipe, mesmo que a perspectiva seja estranha ou as habilidades sejam medíocres.” (Tim Harford, 2016)

Interessante observar que, em ambos os estudos, a equipe de todos os pensadores de valores semelhantes se sentiu bem com o consenso no raciocínio e estava confiante sobre a conclusão – mesmo que na maioria das vezes estivesse incorreta.

Em contraste, as equipes com um pensador diverso estavam inseguras sobre o processo de decisão e inseguras de sua conclusão – mesmo que na maioria das vezes estivessem corretas.

Parece que a introdução da diversidade na equipe causa um pouco de caos no processo e um melhor resultado no pensamento crítico.

Em resumo, duas coisas vêm à mente ao considerar a questão de porque algumas equipes superam outras. Primeiro, sabemos que todas as equipes ficam presas. As melhores equipes minimizam a interrupção ao encontrar rapidamente uma solução.

Essas equipes garantem que todos os membros da equipe tenham voz. É a opinião divergente (a nova ideia) que muitas vezes “descolará” a equipe.

Em segundo lugar, também sabemos que equipes de alto desempenho se tornam proficientes em colaboração e pensamento inovador.

Scrum Masters e líderes de equipe devem se esforçar para construir equipes com diversidade suficiente para garantir que o pensamento de grupo não iniba o pensamento inovador.

A diversidade na equipe pode causar um pouco de caos no processo, mas garantirá o melhor resultado no pensamento crítico. E o pensamento crítico e inovador é um componente necessário de uma equipe Scrum de alto desempenho.

• As 3 coisas que as equipes Scrum erram
  • #1 – Seu backlog é uma lista de pedidos de hambúrguer
    • Qual é o problema?
    • O que posso fazer?
  • #2 – Sua equipe de desenvolvimento não é uma equipe.
    • Qual é o problema?
    • O que posso fazer?
  • #3 – Sua equipe não tem como saber se está no caminho certo para terminar um grande lançamento
    • Qual é o problema?
    • O que posso fazer?
    • Resumindo
  • Os cinco estágios da grandiosidade do time
    • 1 – Aprendendo novas habilidades
    • 2 – Editando sua vida para encontrar sua paixão
    • 3 – Domínio
    •  4 – Colhendo os Resultados
    • 5 – Compartilhando o amor treinando outros
    • Resumo
  • Antipadrões da Equipe de Desenvolvimento Scrum
    • O Papel da Equipe de Desenvolvimento no Scrum
    • Antipadrões da Equipe de Desenvolvimento pelo Evento Scrum
    • Sprint Planning Antipadrões da Equipe de Desenvolvimento
    • Antipadrões de Sprint
    • Antipadrões do Daily Scrum
    • Antipadrões da Equipe de Desenvolvimento: Revisão da Sprint
    • Antipadrões da Equipe de Desenvolvimento na Sprint Retrospective
    • Antipadrões no Nível do Backlog do Produto
  • Antipadrões da equipe de desenvolvimento — Conclusão

As 3 coisas que as equipes Scrum erram

Se você aprendeu Scrum e tentou implementá-lo em qualquer grande organização, provavelmente se deparou com alguns problemas. Conseguir pessoas dedicadas em sua equipe é difícil. Construir equipes multifuncionais é realmente difícil.

Dividir seu trabalho em pequenos problemas que seus clientes gostariam de resolver é provavelmente o mais difícil. Nesse sentido falarei um pouco sobre o que eu vejo como as três coisas mais comuns que as equipes Scrum erram.

Se você está lutando com o acima, verá os sintomas imediatamente. Na verdade, quando estou trabalhando com novas equipes Scrum, essas são as primeiras coisas que procuro.

#1 – Seu backlog é uma lista de pedidos de hambúrguer

Dê uma olhada no seu backlog. Cada item nele tem um título técnico e pouco mais para descrevê-lo? Nesse caso, você tem um acúmulo de pedidos de hambúrguer. Os pedidos de hambúrguer não são questionados.

O cliente geralmente sabe que quer dois hambúrgueres, cebolas grelhadas, ketchup e mostarda. Não é seu trabalho como cozinheiro de pedidos curtos perguntar ao cliente quantas pessoas eles estão tentando alimentar ou se eles têm um problema de colesterol.

No trabalho do conhecimento, é seu trabalho  saber qual problema você está resolvendo, para que possa ser resolvido. Muitas vezes, meus clientes começam a partir de um documento de ‘requisitos’, dividem-no em uma lista de itens obrigatórios, e a equipe os constrói cegamente.

Qual é o problema?

As equipes não podem ser criativas se disserem exatamente o que fazer. Infelizmente, é assim que muitos desenvolvedores estão acostumados a trabalhar. Não precisa ser assim. Se você tratar os desenvolvedores como tomadores de pedidos de hambúrguer, você aumentará os prazos totais de entrega, aumentará o tempo até o primeiro valor, reduzirá a qualidade e desencorajará a inovação.

O que posso fazer?

Apresentar problemas de negócios para equipes Scrum. Melhor ainda, fornecê-los em ordem de importância.

Trabalhe com suas equipes técnicas para representar o valor necessário em um produto em termos de problemas para resolvê-lo e documentá-lo… depois deixe as equipes técnicas descobrirem como resolver os problemas.

Garanta que qualquer pessoa que leia o backlog possa entender os problemas para melhorar a comunicação entre as partes interessadas e as equipes de desenvolvimento e reduzir a necessidade de tradução.

Você contratou pessoas inteligentes, certo? Em seguida, capacite-os a serem brilhantes e capacite-os a enfrentar criativamente os problemas que foram treinados para resolver.

#2 – Sua equipe de desenvolvimento não é uma equipe.

Muitos times agem mais como um time de futebol americano que tem um subtime de quarterbacks, outro subtime de linebackers e outro de kickers que se reúnem todos os domingos para jogar, mas seu time nem sempre recebe os mesmos jogadores.

Qual é o problema?

Suas equipes não estão pensando como equipes, não estão trabalhando como equipes e não estão tendo sucesso como equipes. Eles têm objetivos diferentes e concorrentes. Esses objetivos raramente se alinham para resolver problemas de negócios de forma eficaz.

Um dos principais benefícios de construir uma equipe multifuncional alinhada ao produto é fornecer à equipe todas as habilidades necessárias para agregar valor e mantê-las focadas nos mesmos objetivos.

Outro problema que costuma ocorrer é quando reunimos as pessoas como equipes, mas elas estão trabalhando em iniciativas que não têm nada a ver umas com as outras.

O que posso fazer?

Meça a temperatura da equipe. Eles têm os mesmos objetivos? Eles realmente agem como uma equipe? Eles trabalham como uma equipe? Se eles não tiverem os mesmos objetivos, conserte isso primeiro.

Esqueça o Scrum. Esqueça o ágil. Boas equipes resolvem problemas. Reduza a quantidade de trabalho em andamento de sua equipe, filtrando adequadamente todas as solicitações em uma única lista de pendências ordenada. É aqui que um Product Owner forte é fundamental.

Trabalhe para construir e aumentar sua equipe de dentro para fora… isso é um problema de pessoas. Comece entendendo os estágios de formação de grupo de Tuckman (Formação, Tempestade, Normatização e Atuação) e ajude a orientar a equipe nessa jornada.

Um Scrum Master forte é um indivíduo chave que eu procuraria para este trabalho difícil.

#3 – Sua equipe não tem como saber se está no caminho certo para terminar um grande lançamento

Qual é o problema?

Quando uma equipe não refina adequadamente um backlog durante uma Sprint, você terá apenas algumas estimativas de Sprints. Isso torna muito difícil saber se a equipe está no caminho certo para atingir marcos importantes.

Se você não sabe, posso garantir que há pessoas em sua organização que querem saber como você está progredindo. Uma coisa comum que ouço é “estamos fazendo Scrum, então não fazemos datas”.

Bem, isso é inaceitável para qualquer um que preencha seus cheques. A menos que você queira continuar tendo reuniões de relatório de status, vamos encontrar outra maneira.

O que posso fazer?

Você pode liberar o plano se refinar regularmente sua lista de pendências. Procure construir conhecimento de domínio, criar uma descrição clara e acompanhar a velocidade de sua equipe.

Um bom lugar para começar é escrever seus itens de backlog na forma de uma história de usuário. Em seguida, escreva bons critérios de aceitação e aplique o modelo INVEST.

Quando sua equipe tem uma boa compreensão dos problemas que estão resolvendo, eles podem estimá-los e entregar as soluções na ordem mais importante.

É comum em círculos ágeis usar pontos de história como um meio para estimar. Se você fizer isso, eles fornecerão um número no eixo Y e o tempo em unidades de Sprints no eixo X. (veja o gráfico abaixo)

Um gráfico do plano de lançamento (como o acima) dará à sua organização visibilidade do seu progresso ao longo do tempo. Se as partes interessadas não gostarem do que veem, elas podem tomar uma decisão de negócios mais cedo.

Mostre o burndown desta versão em cada revisão do Sprint e destaque as atualizações à medida que sua linha ‘Real’ muda ao longo do tempo.

Resumindo

Se você está em uma equipe sofrendo com esses 3 pontos que acabo de destacar, saiba que isso é comum. Mas também saiba que você não precisa sofrer. Pegue essas ideias e melhore sua equipe hoje mesmo.

Eu perdi as maneiras pelas quais suas equipes estão resolvendo esses problemas? Alguma pergunta ficou sem resposta?

Os cinco estágios da grandiosidade do time

1 – Aprendendo novas habilidades

Estamos vivendo em um mundo de desenvolvimento de sistemas complexos mais desconhecido do que conhecido, então como você pode saber o que funciona ou não sem experimentar várias opções diferentes?

Quando um experimento científico falha, o cientista não é considerado um fracasso. Entendemos que mesmo que o experimento não tenha dado certo, algo valioso ainda é aprendido.

Esse processo de aprendizado contínuo é o que permite que as pessoas se tornem incríveis. Então, para iniciar o processo de aprendizado, na sua próxima retrospectiva do Sprint, faça esta pergunta: se você soubesse que este próximo Sprint seria o seu último como equipe, o que você faria de diferente? Estudos mostraram que dar esses pequenos passos evitará que as equipes fiquem exaustas e desistam.

“O quanto você concorda com a afirmação: ‘Eu adoro vir trabalhar’? O que faria você concordar mais com essa afirmação?” – Cartões de Treinamento Retrospectivo (Geoff Watts)

2 – Editando sua vida para encontrar sua paixão

Vimos que aprender é tentar muitas coisas pequenas e diferentes. Na verdade, aprender é uma forma de ganhar oportunidades e escolhas. Infelizmente, não podemos ser especialistas em tudo.

Então, precisamos começar a editar. Pergunte a si mesmo: O que me dá mais alegria? É importante formular a pergunta exatamente dessa maneira.

Normalmente começamos fazendo perguntas baseadas em resultados: O que nos dará mais dinheiro? Quais negócios estão crescendo?; etc. Embora estas sejam excelentes perguntas, fazê-las não é a maneira apropriada de começar.

Digamos, por exemplo, que você editou sua vida e percebeu que adora compartilhar ideias.

Você pode aplicar isso de muitas maneiras diferentes: você pode se tornar um blogueiro, um escritor ou um apresentador de podcast.

Seja o que for que você queira aprender, apenas comece a agir de acordo com isso. Ser incrível significa fazer algo que te inspire. E se no meio do caminho você perceber que não é o seu caminho para a grandiosidade, basta editá-lo e passar para a próxima coisa!

Agora que você descobriu em que quer se concentrar, é hora de dar o próximo passo para a maestria.

“Se o dinheiro de repente se tornasse obsoleto e desnecessário, o que faria você querer continuar trabalhando nesta equipe? Como você pode obter mais disso?” – Cartões de Treinamento Retrospectivo (Geoff Watts)

3 – Domínio

Um ótimo truque é começar simples, até mesmo como um Voluntário para apoiar outros membros da equipe. Troque seu tempo por aprendizado e experiência.

Você precisa fazer isso cada vez mais para ficar melhor em tudo o que você é apaixonado. Por exemplo, se você quer se tornar um incrível Scrum Master, o primeiro passo é criar uma lista de pessoas que já estão modelando o comportamento e as ações que você gostaria de modelar:

Como chegaram aonde estão? Quais livros eles leram ou quais podcasts eles mais ouviram? Qual é a rotina diária deles? Como começar a modelar esses comportamentos e iniciar sua jornada?

Em seguida, prepare-se para o inevitável feedback crítico que você receberá ao continuar sua jornada e paixão. Isso é importante, porque não importa quem você é ou no que está trabalhando, você encontrará antagonistas.

Então, você precisa reconhecer a diferença entre puro ódio e crítica construtiva. A crítica construtiva ajuda você a melhorar.

Quando comecei minha carreira na indústria siderúrgica onde costumávamos ter um ditado:

“O melhor aço é feito do fogo mais quente.”

 4 – Colhendo os Resultados

Quanto mais perto você chega de algo, mais você percebe o quanto ainda falta fazer e isso pode ser algo muito difícil de se lidar. As pessoas muitas vezes perdem o “drive” e, assim, atrapalham seu progresso.

A perda de motivação pode ser tratada criando pequenas linhas de chegada que atuam como marcos intermediários.

Dessa forma, pessoas e equipes sempre manterão seu ritmo. Uma ótima maneira de atingir a(s) meta(s) do Sprint é ter marcos menores ao longo do Sprint e alavancar adaptações de inspeção frequentes e colaboração just in time para validar o que o Product Owner e a equipe aprenderam. Isso pode ajudar a manter o foco e reabastecer o ímpeto.

Descubra o que é mais importante para você agora – FOCO, (Lembre-se do princípio “YAGNI” ).

5 – Compartilhando o amor treinando outros

Agora que você descobriu algo que ama, você pode treinar outras pessoas para traçar seu caminho para a maestria. Como se vê, ajudar outras pessoas é incrivelmente gratificante.

Como funciona esse processo?

A ICF define coaching como uma parceria com um coachee que provoca um processo que o inspira a maximizar o potencial pessoal e profissional.

O coaching começa com uma conversa guiada, onde o foco deve estar sempre no coachee, onde o coaching deve ser um ouvinte genuíno  e fazer perguntas poderosas.

Quando você está nesse estágio, também precisa refletir sobre o estágio 1 – o estágio de aprendizado – e começar a jornada para a grandiosidade novamente, escolhendo uma área de melhoria diferente. Esse é o segredo de ser um eterno aprendiz.

“As quatro leis do aprendizado são explicação, demonstração, imitação e repetição. Para garantir que esse objetivo fosse alcançado, criei oito leis de aprendizado – a saber, explicação, demonstração, imitação, repetição, repetição, repetição, repetição e repetição.” – João Madeira

Resumo

Você pode deixar de ser mediano e começar a ser incrível, mas primeiro você precisa saber por onde começar. Trata-se de superar seu medo e seguir os cinco estágios da grandiosidade: aprender novas habilidades, editar para encontrar sua paixão, dominar, colher os resultados e depois treinar outras pessoas.

Quais são seus maiores, mais loucos e mais loucos sonhos! Você já os escreveu em algum lugar? Como você está progredindo em direção aos seus sonhos loucos?

Não se segure. Se você sempre quis ser um grande Scrum Master ou Empreendedor Product Owner, anote! Volte e anote o primeiro passo que você poderia dar que lhe permitiria atingir o menor objetivo possível. Então comece!

Antipadrões da Equipe de Desenvolvimento Scrum

Depois de abordar o Scrum Master e o Product Owner, este artigo aborda os antipadrões do Time de Desenvolvimento, abrangendo todos os Eventos Scrum, bem como o artefato Product Backlog onde quanto mais soubermos o que procurar mais poderemos apoiar nossos colegas de equipe.

O Papel da Equipe de Desenvolvimento no Scrum

De acordo com o Scrum Guide, o Time de Desenvolvimento “consiste em profissionais que fazem o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint. Somente membros da equipe de desenvolvimento criam o incremento.

As equipes de desenvolvimento são estruturadas e capacitadas pela organização para organizar e gerenciar seu próprio trabalho.”

As equipes de desenvolvimento são, portanto, essenciais para as verificações e contrapesos integrados do Scrum, pois a equipe de desenvolvimento tem o controle exclusivo sobre o Sprint Backlog e está vigiando a definição de pronto.

Geralmente, as equipes de desenvolvimento precisam ter as seguintes características para serem bem-sucedidas:

• Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Product Backlog em Incrementos de funcionalidades potencialmente liberáveis;
• As Equipes de Desenvolvimento são multifuncionais, com todas as habilidades – como equipe – necessárias para criar um incremento de produto;
• O Scrum não reconhece títulos para os membros do Time de Desenvolvimento, independentemente do trabalho realizado pela pessoa;
• O Scrum não reconhece subequipes na Equipe de Desenvolvimento, independentemente dos domínios que precisam ser abordados, como teste, arquitetura, operações ou análise de negócios;
• Os membros individuais da Equipe de Desenvolvimento podem ter habilidades especializadas e áreas de foco, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo.

Fonte: Guia Scrum 2020 .

Embora a direção do Guia do Scrum pareça direta, na prática, algumas pessoas ficam confusas sobre o fato de que o papel “Equipe de Desenvolvimento” é atribuído a um grupo de pessoas, criando assim um sub-time dentro do Time Scrum maior, enquanto os papéis do Scrum Master e Product Owner são atribuídos a indivíduos.

Ainda mais confusa pode ser a situação, quando tanto o Scrum Master quanto o Product Owner também estão criando ativamente o Incremento do Produto, resultando no Time de Desenvolvimento sendo idêntico ao Time Scrum.

Finalmente, o termo Equipe de Desenvolvimento parece limitar o papel a pessoas técnicas, por exemplo, engenheiros de software.

Na minha experiência, com o suporte adequado do Scrum Master, até mesmo advogados e profissionais de marketing podem se sentir confortáveis ​​com a designação de “desenvolvedor” ao utilizar o Scrum para seus propósitos.

Vamos mergulhar em uma série de antipadrões comuns da Equipe de Desenvolvimento que sinalizam aos Scrum Masters que sua equipe precisa de suporte.

Antipadrões da Equipe de Desenvolvimento pelo Evento Scrum

A lista a seguir de antipadrões da equipe de desenvolvimento aborda quatro eventos do Scrum mais o próprio Sprint:

Sprint Planning Antipadrões da Equipe de Desenvolvimento

• Capacidade? A equipe de desenvolvimento superestima sua capacidade e assume muitas tarefas.
  • A equipe de desenvolvimento deve levar em consideração tudo o que pode afetar sua capacidade de entrega. A lista desses problemas é longa: feriados, novos membros da equipe e aqueles em licença de férias, membros da equipe saindo, membros da equipe em licença médica, despesas gerais corporativas, eventos Scrum como práticas como refinamento do Backlog do Produto e outras reuniões para citar alguns.
• Ignorando a dívida técnica: A Equipe de Desenvolvimento não está exigindo capacidade adequada para lidar com a dívida técnica e os bugs durante o Sprint.
  • A regra geral é que cerca de 20% dos recursos são bem gastos a cada Sprint para corrigir bugs e refatorar a base de código. Se o Product Owner ignorar a necessidade desse trabalho e o Time de Desenvolvimento aceitar essa atitude, o Time Scrum se encontrará em uma espiral descendente, transformando-se lenta, mas firmemente em uma fábrica de recursos focada em saída. Sua futura capacidade de entrega de produtos diminuirá.
• Sem folga: A equipe de desenvolvimento não está exigindo 20% de folga do Product Owner.
  • Se a capacidade de uma equipe for sempre superutilizada, seu desempenho diminuirá com o tempo. Isso acontecerá particularmente em uma organização com um negócio diário volátil. Como consequência, todos se concentrarão em realizar suas tarefas. Haverá menos tempo para apoiar os companheiros de equipe ou fazer programação em pares, por exemplo.
  • A equipe não abordará mais questões menores ou urgentes prontamente. Membros individuais da equipe se tornarão gargalos, o que pode impedir seriamente o fluxo dentro da equipe. Por fim, a atitude ‘Estou ocupado’ reduzirá a geração de um entendimento compartilhado entre todos os membros da equipe.
  • A superutilização sempre levará o membro individual da equipe a uma mentalidade menos colaborativa, impedindo a auto-organização. Por outro lado, o tempo de folga permitirá que o Time Scrum aja de forma colaborativa e se concentre no resultado.
• Planejamento muito detalhado: durante o planejamento do Sprint, a equipe de desenvolvimento planeja cada tarefa do próximo Sprint com antecedência. Não se torne muito granular. Um quarto das tarefas é mais do que suficiente para não apenas começar com o Sprint, mas também começar a aprender. O Sprint Backlog é emergente e planejar muito antecipadamente pode resultar em desperdício.
  • Estimativa demais: a equipe de desenvolvimento estima subtarefas. Isso parece contabilidade. Não perca seu tempo com isso.
  • Muito pouco planejamento: A equipe de desenvolvimento está pulando o planejamento completamente. (Ignorar o planejamento é lamentável, pois também é uma excelente oportunidade para falar sobre como difundir o conhecimento dentro da Equipe de Desenvolvimento, para onde a arquitetura está indo ou se as ferramentas são adequadas.
  • Por exemplo, a equipe também pode considerar quem fará par com quem em qual tarefa. A parte de planejamento da equipe de desenvolvimento também é adequada para considerar como reduzir a dívida técnica, veja acima.
  • Líderes de equipe? A equipe de desenvolvimento não apresenta um plano para cumprir sua previsão de forma colaborativa. Em vez disso, um ‘líder de equipe’ faz todo o trabalho pesado e provavelmente até atribui tarefas a membros individuais da equipe.

Antipadrões de Sprint

A maioria dos seguintes antipadrões da equipe de desenvolvimento resulta de falta de foco ou procrastinação:

• Sem limite de WIP: Não há limite de trabalho em andamento. O objetivo do Sprint é entregar um Incremento de Produto potencialmente entregável que agregue valor aos clientes e, portanto, à organização.
  • Este objetivo requer um trabalho focado para realizar o trabalho considerado necessário para atingir o objetivo do Sprint até o final do Sprint. A teoria do fluxo sugere que a produtividade de uma equipe melhora com um limite de trabalho em andamento (WIP). O limite de WIP define o número máximo de tarefas em que uma equipe de desenvolvimento pode trabalhar ao mesmo tempo.
  • Exceder esse número de WIP resulta na criação de filas adicionais que, consequentemente, reduzem o rendimento geral da equipe de desenvolvimento. O tempo de ciclo, que é o período entre o início e o término de um ticket, mede esse efeito.
• Escolha a cereja: A equipe de desenvolvimento escolhe o trabalho.
  • Esse efeito geralmente se sobrepõe ao problema de WIP ausente. Os seres humanos são motivados por gratificações de curto prazo. É bom resolver mais um quebra-cabeça do tabuleiro, aqui: codificar uma nova tarefa.
  • Em comparação com essa correção de dopamina , verificar como outra pessoa resolveu outro problema durante a revisão do código é menos recompensador. Por isso, você costuma notar a fila de tickets na coluna de revisão de código, por exemplo. É também um sinal de que a Equipe de Desenvolvimento ainda não está totalmente auto-organizada. Procure também por eventos Daily Scrum que apoiem essa noção e resolva o problema durante a Sprint Retrospective.
• Quadro desatualizado: A equipe não atualiza os tickets no quadro da Sprint a tempo de refletir os status atuais.
  • O quadro da Sprint, seja ele físico ou digital, não é apenas vital para a coordenação do trabalho do Time de Desenvolvimento. Também é parte integrante da comunicação do Time Scrum com seus stakeholders.
  • Um quadro que não está atualizado afetará a confiança que as partes interessadas têm no Time Scrum. A deterioração da confiança pode, então, causar contramedidas por parte das partes interessadas. O pêndulo (de gestão) pode voltar aos métodos tradicionais como consequência. A estrada de volta ao PRINCE II é pavimentada com tábuas abandonadas.
• Side-gigs: A equipe de desenvolvimento está trabalhando em problemas que não são visíveis no quadro.
  • Embora o desleixo seja desculpável, desviar recursos e ignorar o Product Owner – que é responsável pelo retorno do investimento que a equipe de desenvolvimento está criando – é inaceitável. Esse comportamento também sinaliza um conflito substancial dentro da “equipe”.
  • Dada essa demonstração de desconfiança é provável que os engenheiros não abordaram essa questão aparentemente importante durante o Sprint Planning ou antes, onde a equipe de desenvolvimento provavelmente é um grupo de qualquer maneira.
• Gold-plating: A equipe de desenvolvimento aumenta o escopo do Sprint adicionando trabalho desnecessário aos itens do Product Backlog do Sprint Backlog.
  • Este efeito é muitas vezes referido como estiramento de escopo ou revestimento de ouro. A equipe de desenvolvimento ignora o acordo de escopo original com o Product Owner. Por qualquer motivo, a equipe amplia a tarefa sem consultar previamente o Product Owner.
  • Essa ignorância pode resultar em uma alocação de recursos questionável. No entanto, existe uma solução simples: os desenvolvedores e o Product Owner precisam conversar com mais frequência entre si, criando um entendimento compartilhado desde a visão do produto até o item individual do Product Backlog, melhorando assim o nível de confiança. Se o Product Owner ainda não está colocalizado com a equipe de desenvolvimento, agora seria o momento certo para reconsiderar.

Antipadrões do Daily Scrum

O Daily Scrum é o “evento de inspeção e adaptação” chave para o Time de Desenvolvimento. Se a Daily Scrum não estiver funcionando, baseado na minha experiência, é bem provável que o Time de Desenvolvimento não atinja o Sprint Goal.

Os antipadrões comuns da Equipe de Desenvolvimento do Daily Scrum incluem:

• Sem rotina: o Daily Scrum não acontece no mesmo horário e no mesmo local todos os dias.
  • Embora a rotina tenha o potencial de arruinar todas as Retrospectivas, é útil no contexto da Daily Scrum. Pense nisso como um exercício espontâneo: não pense muito no stand-up, apenas faça. Ignorar as Daily Scrums pode se tornar uma ladeira escorregadia: se você pular uma ou duas Daily Scrums, por que não pular a cada segundo?
• Relatório de status: O Daily Scrum é uma reunião de relatório de status, e os membros da equipe de desenvolvimento estão esperando na fila para “relatar” o progresso ao Scrum Master, ao Product Owner, ou talvez até a uma parte interessada.
• Apenas números de ticket: as atualizações são genéricas com pouco ou nenhum valor para os outros.
  • “Ontem, trabalhei no X-123. Hoje, vou trabalhar no X-129.”
• Resolução de problemas: as discussões são desencadeadas para resolver problemas, em vez de estacioná-los para que possam ser abordados após a Daily Scrum.
• Reunião de planejamento: a equipe de desenvolvimento seqüestra o Daily Scrum para discutir novos requisitos, refinar histórias de usuários ou ter uma espécie de reunião de planejamento (Sprint).
• Orientação perdida: A Daily Scrum serve a um propósito, pois responde a uma pergunta simples: ainda estamos no caminho certo para atingir a Meta da Sprint? Ou precisamos adaptar o plano ou o Sprint Backlog ou ambos? Muitas vezes, a equipe de desenvolvimento não pode responder a essa pergunta imediatamente.
  • A esse respeito, visualizar o progresso em direção ao Sprint Goal é um exercício útil. Remover a tarefa da equipe de desenvolvimento de manter um gráfico de burndown obrigatório do Scrum Guide alguns anos atrás não implica que um gráfico de burndown seja obsoleto.
• Sem uso da idade do item de trabalho: Um membro da equipe de desenvolvimento tem dificuldades em resolver um problema por vários dias consecutivos e ninguém está oferecendo ajuda.
  • Muitas vezes, esse resultado é um sinal de que as pessoas podem não confiar umas nas outras ou não se importarem umas com as outras. Alternativamente, a carga de trabalho da equipe de desenvolvimento atingiu um nível improdutivo, pois eles não podem mais se apoiar. Nota: Claro, o Scrum Guide não menciona a ‘idade do item de trabalho’. No entanto, provou ser uma prática útil.
• Falta de noção: os membros da equipe não estão preparados para a Daily Scrum.
  • “Eu estava fazendo algumas coisas, mas não consigo lembrar o quê. Mas foi importante.”
• Feedback excessivo: os membros da equipe criticam outros membros da equipe imediatamente, provocando uma discussão em vez de levar suas críticas para fora do Daily Scrum.

Antipadrões da Equipe de Desenvolvimento: Revisão da Sprint

• Morte por PowerPoint: Os participantes ficam entediados até a morte por PowerPoint.
  • A base de uma Revisão de Sprint bem-sucedida é “mostre, não conte”, ou melhor ainda: deixe que as partes interessadas conduzam a descoberta.
• As mesmas caras novamente: São sempre as mesmas pessoas da equipe de desenvolvimento que participam, não todos.
  • A menos que a organização dimensione o Scrum com base no LeSS ou Nexus e estejamos falando sobre a Revisão geral da Sprint, esse Antipadrão de Revisão da Sprint é um mau sinal. Para maximizar o aprendizado, a Revisão da Sprint precisa de todos os membros do Time Scrum no convés.
  • O desafio é que você também não pode impor a participação da equipe. Em vez disso, torne-o interessante o suficiente para que todos queiram participar. Se isso não estiver acontecendo, você deve – como Scrum Master – perguntar a si mesmo como você contribuiu para esta situação.
• Trapaça: A equipe de desenvolvimento mostra itens que não estão “prontos”.
  • Há uma boa razão para mostrar trabalhos inacabados em algumas ocasiões. O trabalho parcialmente concluído, no entanto, viola o conceito de “Pronto”, um dos primeiros princípios do Scrum.
• Sem Revisão da Sprint: Não há Revisão da Sprint, pois a Equipe de Desenvolvimento não atingiu a Meta da Sprint. Um erro de principiante. Particularmente em tal situação, uma Sprint Review é necessária para criar transparência.

Antipadrões da Equipe de Desenvolvimento na Sprint Retrospective

• #NoRetro: Não há retrospectiva, pois a equipe de desenvolvimento acredita que não há nada a melhorar.
• Não existe um Nirvana ágil onde tudo é simplesmente perfeito. Como as pessoas dizem: tornar-se ágil é uma jornada, não um destino, e sempre há algo a melhorar.
• Buffer dispensável: A equipe cancela retrospectivas se for necessário mais tempo para atingir o objetivo da Sprint. A retrospectiva como reserva de emergência da Sprint é um sinal comum do culto à carga Scrum.
  • Acredito que seja um antipadrão ainda pior do que não ter uma retrospectiva, porque presumivelmente não há nada para melhorar. Isso é apenas uma falácia muito humana que beira a arrogância. No entanto, cancelar aleatoriamente uma retrospectiva para atingir um Sprint Goal é um sinal claro de que a equipe não entende princípios básicos, como empirismo e melhoria contínua.
  • Se o Time Scrum repetidamente não atingir o Objetivo do Sprint, ele deve inspecionar o que está acontecendo aqui. Adivinha qual evento Scrum é projetado para esse propósito?
• Lamentação extensa: A Equipe de Desenvolvimento usa a retrospectiva principalmente para reclamar da situação e assume o papel de vítima.
  • A mudança requer reflexão e, ocasionalmente, é um bom exercício para desabafar. No entanto, não seguir em frente depois de identificar problemas críticos e tentar mudá-los desafia o propósito da retrospectiva.
• Product Owner não-grata: O Product Owner não é bem-vindo à retrospectiva.
  • Algumas pessoas ainda acreditam – por qualquer motivo – que apenas os membros do Time de Desenvolvimento e o Scrum Master devem participar da retrospectiva do time. O Guia do Scrum refere-se ao Time Scrum, incluindo o Dono do Produto . Faz isso por uma boa razão: a equipe vence junto e a equipe falha junto. Como isso deveria funcionar sem o Product Owner?

Antipadrões no Nível do Backlog do Produto

• Sem tempo para refinamento: a equipe não tem sessões de refinamento suficientes, resultando em um backlog de baixa qualidade. O Guia do Scrum aconselha gastar até 10% do tempo da Equipe de Desenvolvimento no refinamento do Backlog do Produto. O que é uma boa decisão de negócios: nada é mais caro do que um recurso que não agrega valor.
• Muito refinamento: a equipe tem muitas sessões de refinamento, resultando em um backlog muito detalhado. Muito refinamento também não é saudável.
• Equipe Submissa: A Equipe de Desenvolvimento segue submissamente as demandas do Dono do Produto. Desafiar o Product Owner se sua seleção de problemas é o melhor uso do tempo do Time de Desenvolvimento é a obrigação mais nobre de cada membro do time: por que devemos fazer isso?

Antipadrões da equipe de desenvolvimento — Conclusão

Dado o papel essencial que a Equipe de Desenvolvimento tem que cumprir para tornar o Scrum bem-sucedido, não é surpresa que existam muitos antipadrões da Equipe de Desenvolvimento a serem observados. A boa notícia, porém, é que muitos deles estão inteiramente sob o controle do Time Scrum. Tudo o que é preciso para enfrentar esses antipadrões para a equipe é ter o exercício continuo de inspecionar e se adaptar. Por que não usar sua próxima retrospectiva para isso?

@agilepracticecenter

O que o time Scrum deve fazer durante a primeira sprint?

Quais são as duas coisas que a equipe de desenvolvimento faz durante a primeira sprint?

O que deve ser feito na primeira sprint?

Qual reunião é realizada no primeiro dia da Sprint?