você está aqui: Home → Coluna do Cesar Brod

De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.

Não é Scrum se...

Por Cesar Brod

Data de Publicação: 23 de Setembro de 2013

O Mark Levison mantém o excelente blog Notes from a Tool User, leitura obrigatória para todos os praticantes e simpatizantes do Scrum e metodologias ágeis em geral. Em seu post de 17 de setembro de 2013 Mark apresentou uma "tabela de verificação" para um ambiente Scrum que, gentilmente, permitiu que eu traduzisse para meus leitores.

As regras do Scrum são simples mas, com frequência, as pessoas esquecem que um Scrum de verdade requer espírito, paixão e compromisso - e o envolvimento de toda a equipe.

Aqui está uma tabela com algumas das muitas coisas que percebi como um sinal de problema. Não é Scrum se ...

Problema	Porque isso é um problema	Uma alternativa
... a equipe é informada da sua velocidade.	A velocidade é uma ferramenta que auxilia na predição de quando você terá um certo número de funcionalidades entregues, servindo como apoio no planejamento dos próximos Sprints. Ela não é uma medida para a produtividade.	Permitir que a equipe descubra a taxa de completude de seu trabalho.
... um diagrama de fluxo de trabalho (como um burndown chart) é confundido com a realidade.	Todos estes diagramas e gráficos são modelos que dão uma ideia sobre o que está acontecendo. Eles apenas medem quantidade, não qualidade. Eles também não apontam o que está completo.	Todos estes gráficos são úteis. Ao invés de procurar por gráficos melhores, tente Genchi Genbutsu: verifique você mesmo. Visite a equipe e veja quais funcionalidades estão prontas, como prática da Revisão do Sprint.
... você usa o quadro de tarefas do Scrum para micro-gerenciar membros da equipe.	Espero que isso seja auto-evidente.	O Scrum é focado no sucesso da equipe. Dê uma chance para a auto-organização. As equipes devem aprender, por si próprias, a melhor maneira de trabalhar de forma eficaz, em conjunto.
... você exige Boas Práticas.	Não importa o quâo boa seja determinada prática (ou seja, Desenvolvimento Baseado em Testes, Testes Unitários, etc). A obrigatoriedade leva ao ressentimento e à adoção sem o devido entendimento. O Scrum tenta incentivar a diversidade de ideias e opiniões do todo, não apenas de uns poucos ungidos.	Permita que cada equipe desenvolva e aprimore suas práticas. Dê a eles o melhor suporte e a melhor informação possível. Eles encontrarão, com frequência, as melhores opções. Mantenha o foco nos resultados e não nas práticas. Crie uma comunidade de práticas para o compartilhamento do conhecimento.
... os membros das equipes mudam com frequência.	A criação de uma equipe de alto desempenho requer a constância de seus membros.	Crie equipes estáveis.
... você trata seu Dono do Produto como um Analista de Negócios com um nome de cargo melhor.	O Dono do Produto (Product Owner) precisa da capacidade de ver o produto como um todo e da autoridade para tomar decisões que possam custar um ou dois sprints da equipe (talvez USD 150.000) sem que suas escolhas sejam ignoradas.	Encontre pessoas dedicadas, que entendam da área de Produto, e dê a elas um treinamento básico de Scrum. Confie nelas para que tomem as decisões corretas quanto às funcionalidades do produto.
... você transforma, em um passe de mágica, todos os seus gerentes de projeto em Scrummasters.	Muitos gerentes de projeto não querem ser Scrummasters.	Pergunte às pessoas quais os papéis que elas desejam assumir. Dê a elas um pequeno espaço de tempo para que elas assumam o papel escolhido e percebam se ele é bom para elas. Não presuma algo com base em cargos e papéis atuais. Por fim, tenha em mente que nem todas as pessoas são compatíveis com o Scrum.
... sua estrutura organizacional não muda.	Equipes Scrum necessitam de uma organização menos formal e mais apoio.	As organizações ágeis tornam-se, tipicamente, menos hierárquicas e mais flexíveis com o tempo.
... você alimenta suas equipes com User Stories ou funcionalidades para o produto.	Quando as pessoas não estão comprometidas com a criação de histórias de uso ou descrição de funcionalidades, desde a sua concepção até a entrega, a compreensão e o engajamento são reduzidos.	A criação coletiva do conhecimento é mais eficaz que a simples transferência do conhecimento. Envolva a equipe na criação do Product Backlog.
... você transforma as histórias em tarefas para a equipe.	A mesma questão do item acima: você dissocia as pessoas das Histórias que estão construindo.
... você mantém os papéis existentes (Desenvolvedor, Testador, Analista de Negócios, etc)	Papéis formais criam gargalos e incentivam o trabalho individual. Adicionalmente, eles encorajam a transferência de tarefas.	O Scrum requer o trabalho colaborativo. Dentro da equipe, ignore qualquer cargo formal. O objetivo é o trabalho conjunto de qualidade, não a divisão de tarefas.
... seu backlog de obstáculos permanece imutável.	O Scrum implica na melhoria da forma como trabalhamos. Uma lista de obstáculos imutável é sinal da falta de engajamento de todos em melhorar a forma de trabalho.	Escolha um ou dois obstáculos por sprint; encontre algo pequeno a ser melhorado com relação a estes obstáculos. Pratique o Kaizen verdadeiro (a insatisfação permanente com o estado atual das coisas). Com frequência, as pequenas melhorias têm um grande efeito na moral da equipe.
... você tem fases em seu trabalho: requisitos, modelagem, desenvolvimento ...	Não há fases distintas.	Espera-se que uma equipe Scrum produza produtos funcionais já no primeiro sprint. Na prática, isso é difícil de se conseguir logo de cara, mas deve permanecer como um objetivo. Mais do que isso, não há fases separadas dentro de um sprint. As equipes mais eficazes encontram formas de criar testes de aceitação antes de começar o trabalho de desenvolvimento.
... você segue repetindo as mesmas ações e obtendo os mesmos resultados.	O Scrum deve desafiar o status quo. Quando você cria um novo status quo, o Scrum deve, novamente, desafiá-lo.	O Scrum convida a um paradigma mental verdadeiramente Kaizen - Parabéns! Atingimos uma grande melhoria, o que nos permite atingir ainda uma nova melhoria logo adiante.
... seu foco está nas ferramentas e não nas pessoas.	Lembre-se: indivíduos e interações são mais importantes que processos e ferramentas.	As ferramentas são importantes, mas elas não devem ser nosso foco. Use as ferramentas apenas se as equipes concordam que elas auxiliam em seu sucesso e não porque há qualquer tipo de exigência da gerência.
... os membros de sua equipe não se sentem profissionalmente desafiados ou emocionalmente satisfeitos.	O Scrum deve ser divertido.	Revise tudo nesta lista que leva à dissociação, etc. Lembre-se: leva anos para trazer as pessoas a este estado de espírito plenamente propício ao Scrum. Um espírito perdido exigirá meses, se não anos, para ser recriado.

Mesmo com todas estas observações, tenha em mente que o Scrum, por si só, não é o ponto mais importante. A verdadeira questão é entregar um trabalho de qualidade, algo que conseguimos fazer com equipes de alto desempenho. O Scrum é uma ferramenta para criar estas equipes, nada além disso.

Obrigado a Neil Killick, Neil Johnson, Amy Neil e Marc Andre-Morriset por suas sugestões, aqui representadas em espírito, se não na cópia exata de seus tuítes.

Muito mais sobre Scrum aqui!

Sobre o autor

Cesar Brod usa Linux desde antes do kernel atingir a versão 1.0. Dissemina o uso (e usa) métodos ágeis antes deles ganharem esse nome. Ainda assim, não está extinto! Escritor, consultor, pai e avô, tem como seu princípio fundamental a liberdade ampla, total e irrestrita, em especial a do conhecimento.

Mais sobre o Cesar Brod: [ Linkedin ] | [ Twitter ] | [ Tumblr ].

Veja a relação completa dos artigos de Cesar Brod