Na semana passada comecei a falar sobre o catálogo de cheiros do SCRUM escrito pelo Mike Cohn, que procura identificar, logo cedo, quando as coisas vão mal em um projeto (perda de ritmo, galinhas falantes e porcos faltantes). Outros cheiros catalogados pelo Mike são os seguintes:
- Hábitos persistentes: é normal que cada grupo comece um projeto trazendo para ele seus hábitos de trabalho em equipe e individuais, mas é importante que, quando um mau hábito é identificado, ele seja imediatamente corrigido. Um dos termômetros do Sprint é o Burndown Chart, o quadro de registro do consumo de horas do projeto. Quando as horas efetivamente consumidas flutuam muito com relação às horas previstas, há algo de errado no planejamento ou na execução do projeto.
- O ScrumMaster delega trabalhos: especialmente em equipes ainda não habituadas ao SCRUM, é normal que exista uma expectativa que o ScrumMaster, como um gerente de projetos, distribua os trabalhos a serem feitos. Isto é errado. O ScrumMaster auxilia a equipe, removendo os obstáculos à execução do projeto. Cada membro da equipe deve escolher as tarefas que executará, de acordo com a sua competência e negociando com os demais membros do grupo.
- A reunião diária é para o ScrumMaster: também um sintoma clássico da falta de familiaridade com o SCRUM, manifesta-se com a equipe fazendo para o ScrumMaster o relato dos trabalhos. A reunião tem que ser para a equipe. Quando um membro compromete-se em entregar uma tarefa, ele compromete-se com a equipe e não com o ScrumMaster. Não é papel do ScrumMaster reclamar da entrega ou não de tarefas, mas entender os obstáculos que impediram a sua realização e removê-los.
- Cargos especializados: acontece quando as pessoas entram na equipe com cargos de "testador", "chefe de desenvolvimento" e outros. Quando alguém entra com o papel de "testador", por exemplo, os demais podem ter a impressão de estar "liberados" de participar de testes do projeto. Assim como um "chefe" de qualquer coisa pode dar uma falsa impressão de hierarquia. Dentro de uma equipe SCRUM, todos devem ter o espírito "estamos nessa juntos" e assumir responsabilidades idênticas perante o projeto. Claro que vai ser impossível uma equipe formada apenas por generalistas, que saibam tudo de tudo, mas o espírito é esse. O que eu procuro fazer é eliminar os títulos e cargos na apresentação da equipe, observar a escolha de tarefas de cada um (tipicamente, dentro das áreas de maior conforto) e tentar incentivar a colaboração especialmente quando há a identificação de obstáculos para os quais sinto que "o olhar de um outro colega" pode trazer nova luz às dificuldades. Claro que sempre tomando o cuidado de não delegar tarefas.
Para mais informações sobre esse assunto, vale a pena ler o blog do Henri Knikberg, em especial o seu artigo 10 maneiras de ferrar com o SCRUM e o XP. O Huitale é outro blog ao qual se deve prestar atenção. Nele estão três artigos bastante pertinentes ao assunto:
- Common Scrum Pitfalls - self-organizing teams taken to extreme: nesse artigo o autor critica o que acontece quando uma das principais características do SCRUM, a auto-organização das equipes, é levada ao extremo;
- Common Scrum Pitfalls - Killing your Scrum with a bad Definition of Done: aqui a crítica é sobre o que é considerado um trabalho completo e sobre quem deve definir o que significa um trabalho completo;
- Common Scrum Pitfalls - Weak Product Owner: por fim, esse artigo aponta os perigos de se ter um fraco patrocinador do projeto.
Artigo produzido para o Dicas-L
Voltar para a Parte 1 | Mais sobre esse assunto
