Como reconhecer respostas plausíveis, porém incorretas, sobre Scrum; separar regras do framework de práticas Agile populares; proteger a autogestão e o empirismo; e raciocinar sobre os equívocos mais frequentes da prova
Tempo estimado de leitura: 30 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá ser capaz de reconhecer as armadilhas mais comuns da relacionadas à autoridade do , à accountability do , à , e , à atribuição de tarefas, , User Stories, , gráficos de burn, , entrega do ,, alterações no , e à fronteira entre o básico e o .
Introdução: as respostas erradas mais difíceis geralmente parecem boa gestão de projetos
Muitas armadilhas da não são absurdas. São práticas que as pessoas já viram funcionar em outros contextos e que, depois, são promovidas incorretamente a .
O acumulou mitos quase tão rapidamente quanto acumulou adeptos. Alguns vieram da gestão tradicional de projetos: gestores atribuindo tarefas, reuniões de status, gates de aprovação e escopo fixo de . Outros vieram de práticas vizinhas: User Stories, ,, e Burndown Charts. Outros ainda vieram de frameworks de escala ou de adaptações organizacionais.
O Scrum Guide foi publicado pela primeira vez em 2010, em parte para oferecer uma definição comum de .O Guia de 2020 tornou-se deliberadamente ainda menos prescritivo, removendo convenções históricas, como as três perguntas da , e enfatizando a estrutura mínima necessária do framework.
Isso significa que um candidato à enfrenta dois desafios simultâneos. É preciso saber o que o exige e resistir à tentação de acrescentar aquilo que o não exige apenas porque é popular.
A prova frequentemente cria alternativas plausíveis ao combinar um fato verdadeiro com uma implicação falsa. O pode cancelar uma - verdadeiro. Logo, o pode cancelá-la sempre que surgir uma funcionalidade de alta prioridade - falso. O escopo pode mudar durante uma - verdadeiro. Logo, o pode ser alterado casualmente - falso. Uma demonstração pode ocorrer durante a - verdadeiro. Logo, a é uma reunião de demonstração - falso.
A estratégia mais segura é reconstruir o framework. Pergunte quem possui a accountability, qual propósito do evento está sendo protegido, qual artefato ou compromisso importa e se a resposta preserva transparência, inspeção, adaptação, , qualidade e valor.
A mesma estratégia protege organizações reais. Compreender de forma equivocada pode centralizar decisões, enfraquecer a autoridade do , transformar em meros receptores de tarefas, atrasar feedback e criar burocracia de release. Corrigir mitos não é apenas trivia de certificação; é restaurar o sistema operacional que o pretende criar.
Este capítulo percorre, uma a uma, as armadilhas mais comuns. Para cada uma, veremos por que a resposta errada parece plausível, qual regra ou princípio a corrige e qual heurística de prova pode ser recuperada rapidamente da memória.
Como as armadilhas da são construídas
A maioria das armadilhas utiliza um de quatro padrões: substituição de papéis, distorção de eventos, elevação de prática opcional a requisito ou confusão entre compromissos.
Padrão da armadilha
O que acontece
Exemplo
Substituição de papel
Uma responsabilidade semelhante à de um gestor é atribuída ao ou ao .
atribui tarefas.
Distorção de evento
Um evento passa a funcionar como uma reunião tradicional com outro propósito.
vira reunião de status.
Prática opcional apresentada como obrigatória
Uma técnica útil é apresentada como obrigatório.
obrigatórios.
Confusão de compromisso
Escopo previsto, qualidade ou objetivos são misturados.
PBIs selecionados tratados como compromisso imutável da .
Figura 1. Quando uma alternativa parecer familiar, reconstrua o em vez de confiar apenas na familiaridade.
Armadilha 1 - como gerente do time
O mito: o é um delivery manager que supervisiona , toma decisões operacionais, atribui trabalho, acompanha desempenho individual e garante que todos sigam o plano.
Por que parece plausível: muitas organizações apenas renomeiam project managers como Masters sem alterar as estruturas de autoridade.
A realidade do é diferente. O não possui hierarquia interna e é autogerenciado. O é accountable por estabelecer o e pela eficácia do , e não por gerenciar pessoas.
O lidera por meio de coaching, ensino, facilitação, e influência organizacional. Ele não se torna chefe do nem dos .
Heurística de prova
Se a resposta der ao autoridade hierárquica sobre , tarefas, estimativas ou decisões de produto, ela quase certamente está errada.
Armadilha 2 - como comitê
O mito: produtos importantes precisam de um comitê de Product Owners para que as áreas de negócio votem nas prioridades.
Por que parece plausível: produtos complexos possuem muitos stakeholders e interesses concorrentes.
O cria deliberadamente um único accountable. O pode representar muitos stakeholders e pode delegar atividades de gestão do , mas a accountability permanece com uma única pessoa.
Isso não significa que o ignore os stakeholders. Significa que as decisões finais de ordenação e valor são coerentes o suficiente para serem inspecionáveis. Quem deseja mudanças no procura convencer o .
Memorize
= uma pessoa, não um comitê.
Armadilha 3 - distribui tarefas
O mito: a identifica o trabalho e, em seguida, o distribui as tarefas para os mais adequados.
O Guia atribui a accountability oposta. Os criam o e decidem como os Items selecionados se transformarão em um . Ninguém mais lhes diz como transformar PBIs em Incrementos de valor.
Um pode ajudar o time a aprender a planejar melhor, tornar restrições de habilidade visíveis ou facilitar conversas difíceis. Entretanto, distribuir tarefas enfraquece a .
Regra rápida
ordena o trabalho do produto. decidem como realizá-lo. viabiliza o sistema.
Armadilha 4 - como reunião de status
O mito: cada Developer relata ontem, hoje e bloqueios ao ou a um gestor.
Por que parece plausível: o formato histórico das três perguntas foi amplamente utilizado, e organizações frequentemente usam reuniões diárias para reporte.
O Guia atual define a como um evento de 15 minutos para os inspecionarem o progresso em direção ao e adaptarem o . Os escolhem a estrutura e as técnicas.
O garante que o evento aconteça e seja compreendido, mas são os que o conduzem. Ele não foi concebido para que indivíduos reportem status para cima.
Se as três perguntas ajudarem um time a manter o foco no , elas podem ser usadas. Elas não são obrigatórias.
Heurística de prova
= inspecionam o progresso em direção ao e adaptam o plano. Reporte de status ao = armadilha.
Armadilha 5 - como gate de aprovação
O mito: o trabalho só se torna aceito, liberável ou oficialmente Done depois que o ou os stakeholders o aprovam na .
Isso mistura qualidade com aprovação de stakeholder. O trabalho passa a integrar um quando atende à . A não cria o status Done.
A Review inspeciona o resultado da e determina adaptações futuras. Stakeholders colaboram sobre o que fazer a seguir. Eles não funcionam como um conselho formal de aprovação de release dentro do .
Regra crítica
A determina se o trabalho faz parte de um - não a aprovação na .
Armadilha 6 - como simples demo
O mito: o time mostra as funcionalidades concluídas, recebe aplausos e a reunião termina.
Uma demonstração pode ser útil, mas o propósito do evento é mais amplo. e stakeholders inspecionam o resultado da , discutem o progresso em direção ao , analisam mudanças no ambiente e colaboram sobre futuras adaptações.
O Guia chama explicitamente a de sessão de trabalho e alerta contra reduzi-la a uma apresentação.
Pergunta para a Review
Não apenas: 'O que construímos?'. Pergunte: 'Com base no que aprendemos, o que devemos fazer a seguir?'
Armadilha 7 - Confundir com
Os dois eventos inspecionam e adaptam, o que os torna fáceis de confundir.
A concentra-se no resultado do produto, nos stakeholders, no progresso em direção ao , em mudanças de mercado/ambiente e em futuras adaptações do .
A concentra-se na qualidade e na eficácia da forma de trabalho do : indivíduos, interações, processos, ferramentas, , problemas e melhorias.
Dimensão
Objeto principal
Resultado do produto / direção do produto
Eficácia do time / forma de trabalhar
Participantes
+ stakeholders-chave
Adaptação típica
/ futuras decisões de produto
Processos, colaboração, práticas de qualidade
( de 1 mês)
Máx. 4 horas
Máx. 3 horas
Posição
Penúltimo evento da
Conclui a
Armadilha 8 - são obrigatórios
são uma técnica popular de , mas o Scrum Guide não os exige.
O pode conter um atributo de tamanho, e os que realizarão o trabalho são responsáveis pelo . A unidade não é prescrita.
Um time pode usar , T-shirt sizes, contagem de itens, baseado em fluxo ou outra técnica útil. Questões da que afirmem ' exige ' estão erradas.
Armadilha 9 - User Stories são obrigatórias
User Stories são um formato útil de originado fora do , fortemente associado ao e à prática .
O exige apenas um . Seus itens podem assumir qualquer forma apropriada ao domínio, desde que se tornem transparentes o suficiente para planejamento e entrega.
Um controle de segurança, item de pesquisa, mudança de compliance, capacidade operacional, defeito, experimento ou melhoria técnica não precisa de uma frase com persona fictícia para ser um trabalho legítimo.
Armadilha 10 - é obrigatório
pode ajudar os a discutir pressupostos e estimar relativamente por meio de revelação simultânea. O não o exige.
Ele não é um evento , uma cerimônia nem uma parte obrigatória da ou do refinement. Os escolhem técnicas de e estimativa adequadas ao contexto.
Armadilha 11 - Burndown é obrigatório
O Scrum Guide menciona explicitamente burn-downs, burn-ups e cumulative flows como práticas que podem ser usadas para forecast de progresso. A mesma passagem afirma que elas não substituem o .
Esse é um forte indício de prova: o reconhece os gráficos, mas não os torna obrigatórios.
Um pode não usar qualquer burn chart e ainda assim utilizar plenamente.
Armadilha 12 - é uma métrica oficial do
não é definida como artefato, compromisso, accountability, evento, pilar, valor ou métrica obrigatória do .
Times que usam podem calcular os pontos concluídos por e usar valores históricos para local. Isso pode ser útil. Ainda assim, não transforma em métrica oficial do .
Tratar como KPI de desempenho cria problemas adicionais: escalas de pontos são locais, os valores variam naturalmente e metas podem incentivar manipulação em vez de entrega de valor.
Prática
Status correto
Opcional
User Stories
Opcional
Opcional
Burndown / Burnup
Prática opcional de
Sinal histórico / de local e opcional
Requisito do ?
Nenhuma das alternativas acima
Heurística sobre práticas opcionais
Se uma resposta disser que o DEVE usar uma técnica conhecida, verifique se ela aparece como elemento essencial no Scrum Guide. Na maioria das vezes, não aparece.
Armadilha 13 - só pode ser entregue após a
Esta é uma das regras explícitas mais claras do Scrum Guide. Vários Incrementos podem ser criados durante uma , e um pode ser entregue aos stakeholders antes do término da .
A jamais deve ser considerada um gate para liberação de valor.
A condição é Done. O trabalho deve atender à antes de fazer parte de um . O momento do release é uma decisão de produto/negócio, e não um sistema de permissão da .
Memorize exatamente
Um Done pode ser entregue antes da . A nunca é um gate de release.
Armadilha 14 - cancela a
Essa afirmação é parcialmente verdadeira, o que a torna perigosa.
Somente o possui autoridade para cancelar uma . Entretanto, o não afirma que o pode cancelá-la por qualquer motivo.
Uma pode ser cancelada se o se tornar obsoleto. Obsoleto significa que o objetivo deixou de ser relevante ou valioso diante do contexto alterado - e não simplesmente que a entrega ficou difícil, um PBI atrasou ou o time está atrás do esperado.
O cancelamento deve ser raro, porque Sprints são curtas e o cancelamento é disruptivo.
Regra em duas partes
Autoridade: somente o . Condição: o torna-se obsoleto.
Armadilha 15 - O não pode mudar
O pensamento tradicional de escopo fixo frequentemente invade o . O mito diz que todos os PBIs selecionados na constituem um compromisso vinculante e não podem mudar até o término da .
O Guia atual afirma que o escopo pode ser esclarecido e renegociado com o à medida que mais é aprendido.
O limite é o . Nenhuma mudança deve ser feita de forma a colocá-lo em risco, e o fornece flexibilidade no trabalho exato necessário para alcançá-lo.
e podem, portanto, ajustar o escopo do quando novos aprendizados sugerem um caminho melhor para o mesmo objetivo.
Figura 2. O protege o foco e, ao mesmo tempo, permite adaptação de escopo com base no aprendizado.
Armadilha 16 - é apenas um resumo dos PBIs selecionados
O não é uma lista de trabalho. Ele é o único objetivo da e o compromisso do .
Ele cria coerência e permite flexibilidade. Se um PBI planejado deixar de ser necessário ou surgir uma solução diferente, os podem adaptar o trabalho exato preservando a razão pela qual a existe.
Um fraco, como 'concluir os tickets 123, 124 e 125', remove grande parte dessa flexibilidade porque apenas repete o escopo.
O é criado colaborativamente durante a e finalizado antes do término do evento.
Armadilha 17 - Não atingir o significa que a deve ser cancelada
A dificuldade de atingir o não o torna automaticamente obsoleto.
Um torna-se obsoleto quando novas evidências de negócio, mercado, tecnologia ou estratégia fazem com que o objetivo deixe de valer a pena.
Se o objetivo ainda é valioso, porém ficou mais difícil do que o esperado, os inspecionam e adaptam o e colaboram com o sobre o escopo. Eles não cancelam a apenas para esconder um erro de forecast.
Armadilha 18 - pode adicionar trabalho diretamente ao
O é membro do e colabora estreitamente com os , mas o é um plano criado por e para os .
O pode discutir novas informações e negociar escopo. Ele não insere unilateralmente tarefas ou PBIs no plano dos .
Se um trabalho urgente realmente apoiar o , o pode se adaptar. Se colocar o objetivo em risco, ele não deve simplesmente ser imposto à .
Armadilha 19 - Stakeholders podem repriorizar diretamente
Stakeholders são essenciais para feedback e insight de produto, mas o cria um caminho claro para a ordenação do produto.
Quem deseja alterar o procura convencer o . Atribuir trabalho diretamente aos contorna a accountability do e enfraquece o foco da .
Stakeholders podem colaborar com quando isso for útil, especialmente durante a e ao longo do trabalho de produto, mas colaboração não é autoridade de comando.
Armadilha 20 - Todo PBI deve ser concluído para que a tenha sucesso
Os Items selecionados constituem um forecast do que os acreditam que podem concluir. O é o compromisso.
Uma ainda pode criar valor significativo quando alguns itens previstos mudam ou permanecem inacabados, desde que o seja atingido e o trabalho contabilizado como atenda à .
Por outro lado, concluir todos os PBIs selecionados não torna automaticamente a bem-sucedida se o resultado pretendido pelo não foi atingido ou se as hipóteses de valor se mostraram incorretas.
Armadilha 21 - Trabalho parcial pode ser apresentado como Done na
O Guia é rigoroso: o trabalho que não atende à não pode ser liberado nem apresentado na como parte do .
Ele retorna ao para consideração futura.
O time pode discutir trabalho inacabado ou aprendizados, mas não deve criar falsa transparência apresentando trabalho incompleto como concluído.
Armadilha 22 - é a mesma coisa que
são uma prática complementar e opcional que descreve comportamento ou condições esperadas específicas de um item.
é o estado formal de qualidade do produto exigido para que o trabalho se torne parte de um .
Um PBI pode satisfazer todos os seus e ainda não estar Done se integração, segurança, testes, documentação ou outras medidas de qualidade da estiverem incompletas.
Armadilha 23 - Refinement é um evento
é uma atividade contínua. Ele não é o sexto evento e não possui oficial no .
Times frequentemente agendam sessões de refinement porque elas são úteis. A reunião agendada é uma prática, e não um evento obrigatório do framework.
Armadilha 24 - Elementos do pertencem ao básico
é um framework da .org para escalar entre aproximadamente três e nove Teams trabalhando em um produto.
Ele se apoia no e adiciona elementos como , Cross-Team Refinement, ,, e Integrated .
Esses elementos não fazem parte do básico descrito no Scrum Guide. Questões da sobre não devem ser respondidas com estruturas específicas do , a menos que o enunciado mencione explicitamente .
Limite do
Scrum Guide define . Guide define . é complementar, não básico.
As afirmações 'quase verdadeiras' mais perigosas
Afirmação
Veredito
Nuance ausente
O pode cancelar uma .
Incompleta
Somente se o se tornar obsoleto.
O escopo não pode mudar durante a .
Falsa
O escopo pode ser esclarecido/renegociado sem colocar o em risco.
inclui uma demo.
Pode ser verdade
Mas a Review é uma sessão de trabalho mais ampla para inspeção e adaptação.
remove impedimentos.
Incompleta
Ele causa a remoção; não precisa resolver pessoalmente todo problema.
estimam o trabalho.
Verdadeira em princípio
Eles são responsáveis pelo , mas não exige .
Burndown é usado no .
Pode ser verdade
Prática útil e opcional de , não obrigatória.
Trabalho Done é mostrado na .
Verdadeira
Mas também pode ser entregue antes da Review.
O é um compromisso.
Falsa
é o compromisso do .
Exemplo prático - uma , dez armadilhas de prova
Imagine um responsável por uma API bancária regulada. A produz um : 'Permitir que parceiros-piloto façam rotação de certificados de autenticação sem interromper a autorização de pagamentos.' Os fazem forecast de seis PBIs.
No Dia 2, um gerente sênior participa da e pede status individual a cada Developer. Em seguida, o atribui duas tarefas bloqueadas. Duas armadilhas já apareceram. A pertence aos para inspecionar o progresso em direção ao , e o não distribui trabalho.
No Dia 4, um stakeholder pede diretamente a um Developer que adicione um novo endpoint de relatório de fraude. O concorda que a funcionalidade tem valor, mas ela não apoia o e consumiria grande parte da capacidade restante. A resposta correta não é 'o escopo nunca pode mudar' nem 'stakeholders podem mudar prioridades'. O avalia o limite do . A nova funcionalidade deve voltar à ordenação do em vez de colocar o objetivo atual em risco.
No Dia 5, um PBI de certificado é estimado com por meio de . Outro membro afirma que o processo deve ser usado porque o o exige. Isso é falso. Os são responsáveis pelo , mas não prescreve nem .
No Dia 7, uma mudança Done atende à e pode ser liberada com segurança para o piloto. Alguém argumenta que o release deve aguardar a . Outra armadilha: não é gate de release.
No Dia 8, evidências de mercado mostram que o parceiro-piloto abandonou completamente a direção do produto de rotação de certificados e está migrando para outro modelo de autenticação. Agora o próprio pode ter se tornado obsoleto. Somente o tem autoridade para cancelar a .
Suponha, em vez disso, que o parceiro ainda queira o resultado, mas um PBI selecionado se torne desnecessário porque uma solução técnica mais simples foi descoberta. A não deve ser cancelada. e podem renegociar o escopo do preservando o objetivo.
Na , o time demonstra a capacidade ponta a ponta. O evento não deve terminar aí. Stakeholders inspecionam o resultado do produto, discutem novas evidências e o progresso em direção ao e colaboram nas próximas adaptações.
Na Retrospective, o time inspeciona por que gestores continuam transformando a em reporte de status e por que solicitações diretas de stakeholders contornam a ordenação do . Isso não é outra Review; o objeto de inspeção é o sistema de trabalho do time.
Por fim, um arquiteto sugere formar um porque outro time compartilha uma biblioteca. A menos que a organização esteja adotando explicitamente para um produto com múltiplos times, essa accountability do não passa automaticamente a fazer parte do .
Uma única realista exercitou a maior parte das armadilhas comuns da prova. As respostas corretas emergem dos mesmos princípios: accountabilities claras, propósito dos eventos, proteção do ,,, e a fronteira entre obrigatório e práticas opcionais.
Tabela rápida de armadilhas da
Afirmação
Veredito
Correção para memorizar
gerencia
Falso
Sem hierarquia; SM viabiliza eficácia.
Comitê de Product Owners
Falso
Uma pessoa.
= reporte de status
Falso
Evento de inspeção/adaptação dos .
= gate de aprovação
Falso
cria Done; Review inspeciona/adapta.
= apenas demo
Falso
Sessão de trabalho com stakeholders.
Review = Retrospective
Falso
Produto vs. forma de trabalhar.
atribui tarefas
Falso
se autogerenciam.
obrigatórios
Falso
Método de é opcional.
User Stories obrigatórias
Falso
Formato de PBI é opcional.
obrigatório
Falso
Técnica de estimativa opcional.
Burndown obrigatório
Falso
Prática opcional de .
é métrica oficial do
Falso
Métrica local e opcional.
espera pela Review
Falso
Pode ser liberado antes.
PO pode cancelar
Condicional
Somente se o estiver obsoleto.
é fixo
Falso
Pode adaptar sem colocar o objetivo em risco.
é opcional
Falso
Compromisso do .
Refinement é evento
Falso
Atividade contínua.
é básico
Falso
Framework complementar de escala.
Cinco regras que resolvem a maioria das armadilhas
Proteja os limites de accountability: responde por valor e ; são responsáveis pelo plano da e pela implementação; viabiliza e eficácia.
Proteja o propósito dos eventos: Daily = progresso em direção ao ; Review = resultado do produto e adaptação futura; Retro = qualidade e eficácia.
Proteja os compromissos: , e não são intercambiáveis com forecasts ou técnicas opcionais.
Proteja a : respostas que centralizam decisões comuns do time em um gestor ou são suspeitas.
Proteja as fronteiras do framework: práticas opcionais e elementos específicos do não viram requisitos do por serem populares.
Estratégia de prova
Quando duas respostas parecerem razoáveis, prefira a que preserva a accountability explícita do , o propósito do evento, o compromisso, o e a - com o mínimo de processo inventado.
Conclusão: a maioria das armadilhas da são, na verdade, testes de fronteira
A prova não precisa de trivia obscura para se tornar difícil. Os equívocos mais comuns sobre já fornecem respostas erradas suficientemente plausíveis.
O é um verdadeiro líder que serve, e não um gerente que distribui tarefas. O é uma única pessoa accountable, e não um comitê de priorização. autogerenciam seu plano da em vez de reportar diariamente a um controlador.
A trata do progresso em direção ao e da adaptação do plano. A inspeciona resultados de produto com stakeholders e não é um gate de aprovação nem apenas uma demo. A inspeciona qualidade e eficácia da forma como o trabalha.
Técnicas populares criam outra família de armadilhas. User Stories, ,, e burn charts podem ser úteis. Nenhuma é obrigatório. O framework deixa intencionalmente espaço para práticas específicas do contexto.
As regras de e são especialmente importantes. Done vem da , não da aprovação da Review. Incrementos Done podem ser entregues antes da . O é a única pessoa com autoridade para cancelar uma , e o cancelamento está ligado ao tornar-se obsoleto.
O pode se adaptar. Os PBIs selecionados são um forecast; o é o compromisso. Essa distinção permite sem transformar cada em mudança descontrolada.
O exige a mesma disciplina de fronteira. É um framework complementar da .org para escala, construído sobre . Seu Integration Team, seus eventos e seus artefatos não são elementos do básico.
Na minha visão, a preparação mais útil para a prova não é memorizar mitos como correções isoladas, mas perceber o padrão por trás deles. O protege accountabilities claras, ciclos curtos de feedback, , qualidade, valor e . Quando uma resposta substitui silenciosamente um desses elementos por hierarquia, cerimônia, planos fixos ou ferramentas obrigatórias, provavelmente você encontrou a armadilha.
Principais pontos
não é gerente do e não atribui tarefas aos .
é uma pessoa, não um comitê.
é um evento de 15 minutos dos para inspecionar o progresso em direção ao e adaptar o .
As três perguntas históricas da são opcionais.
é uma sessão de trabalho para inspecionar o resultado da e determinar futuras adaptações.
não é um gate de aprovação e não deve ser reduzida a uma demo.
concentra-se na qualidade e eficácia da forma de trabalho do .
, User Stories, , Burndown Charts e não são requisitos do .
não é uma métrica oficial de desempenho do .
Um Done pode ser entregue antes da ; a Review nunca é gate de release.
Somente o tem autoridade para cancelar uma .
Uma pode ser cancelada quando o se torna obsoleto.
O pode ser esclarecido e renegociado à medida que mais é aprendido.
Nenhuma mudança deve colocar o em risco.
é o compromisso do e oferece flexibilidade no escopo exato.
PBIs selecionados são um forecast, não um compromisso imutável.
Trabalho incompleto não pode ser contabilizado como nem apresentado como Done.
é contínuo, e não um evento formal do .
é um framework complementar da .org para escala e não faz parte do básico definido no Scrum Guide.
