Quando você percebe que seu Scrum já não tem mais aquele frescor inicial e precisa resolver isso.
É justamente no dia a dia que o Scrum vai tornando-se cada vez mais importante no conjunto de atitudes de uma empresa ou de uma equipe de projeto. Depois de algum tempo de prática, as ferramentas tornam-se um hábito. Na minha prática, já é muito comum, a partir da primeira reunião com um cliente, começarmos a pensar nos termos do Product Backlog, imaginando como será a formação da equipe e como serão os parceiros de desenvolvimento e quantos Sprints ocorrerão até a entrega final do projeto, ou de cada uma de suas versões. Quando a proposta é feita, muitas vezes em conjunto com um ou mais parceiros de negócios, ela traz embutida o embrião de um Product Backlog e de um cronograma que dará origem ao Release Burndown Chart (que abordaremos no Capítulo 9, “Product Backlog Refinement”).
O perigo de algo que se torna cotidiano, porém, é que esse algo pode começar a se deteriorar sem que a gente perceba. É preciso prestar atenção nos cheiros do Scrum para ver se não há algo de podre no reino da Dinamarca, como diria Hamlet.
Quem usou pela primeira vez o termo “Code Smells” (o cheirinho do código) foi o Kent Beck, criador do Extreme Programming, enquanto ajudava o Martin Fowler em seu livro sobre Refactoring. Segundo Martin, “um método muito extenso é um bom exemplo – apenas de olhar para um código meu nariz começa a se contorcer se eu vejo mais do que uma dúzia de linhas em Java”. Já o meu nariz fica incomodado ao ver que o código está escrito em Java; não que eu tenha algo contra essa linguagem de programação!
A analogia com o “cheiro” é bastante simples. Muitas vezes, sabemos que há algo errado, algo está cheirando mal, mas nem sempre é fácil identificar a origem. Mike Cohn, que muitos já notaram ser uma das minhas fontes preferidas, propôs um catálogo de cheiros do Scrum em 2003, buscando auxiliar na identificação de alguns problemas. A seguir, veremos alguns desses “cheiros”.
Perda de ritmo
Acontece quando os Sprints começam a ter duração variável. É muito importante, para o sucesso do Scrum, que a equipe adquira a naturalidade em seu ritmo, concluindo cada Sprint com algum incremento ao projeto. Se, por qualquer razão, um Sprint tiver a duração de uma semana, outro de duas, mais outro de uma e assim por diante, será impossível que o ritmo adquira uma naturalidade. Eu vejo a tendência de isso acontecer quando o time é formado por “porcos” que têm muitos outros compromissos. Porcos são aqueles que entram com o “toucinho” no projeto, os que devem estar verdadeiramente comprometidos. O Scrummaster deve considerar a duração do Sprint algo sagrado e, se for o caso, conversar com o patrocinador do projeto exigindo a participação do devido porco ou até sugerindo a troca de porcos.
Galinhas falantes
Na reunião diária do projeto, apenas os porcos podem falar. As galinhas, que entram com os ovos, estão envolvidas, mas não comprometidas com o processo. O Mike é totalmente contra permitir que as galinhas se intrometam, mas concorda que elas podem assistir às reuniões. Eu concordo, mas também aceito que, na informalidade, uma galinha tente transmitir a um porco suas ideias, fora das reuniões. Em raros casos, e sempre entre o fim de um Sprint e o começo de outro, aceito a indicação de um porco para promover uma galinha a porco também.
Porcos que faltam
Cada vez mais desenvolvedores trabalham em horários flexíveis. Isso é um problema quando se quer estabelecer um ritmo e tem a ver com o primeiro dos problemas aqui colocados. As reuniões diárias devem ser rápidas, de 15 minutos, aproveitando ao máximo o tempo dos participantes. Os porcos escolhidos devem saber disso e estar de acordo logo no início do projeto. O porco que faltar estará sujeito às decisões dos demais, sem poder negociar nada posteriormente. Mas com equipes que trabalham remotamente? Aí eu sou mais flexível, mesmo reconhecendo que essa flexibilidade é, às vezes, contraproducente e que o Scrummaster acaba tendo a sobrecarga de ficar dando puxões de orelhas aqui e ali. Nesses casos, o que faço é ter vivo um documento compartilhado, no qual as decisões têm seu horário de fechamento. Passado esse horário, quem não contribuiu se sujeita às decisões dos demais.
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 do esforço alocado ao projeto. Quando o esforço efetivamente alocado flutua muito com relação ao esforço previsto, 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 de que o Scrummaster, como faria um antigo gerente de projetos, distribua os trabalhos a serem feitos. Isso é 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 de ser para a equipe. Quando um membro se compromete 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 impedem a sua realização e removê-los. Esse sintoma tende a ser eliminado com a rotatividade do papel do Scrummaster entre os membros da equipe, a cada Sprint (ou a cada poucos Sprints).
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 que estão “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 logo de início, mas o espírito é chegar a esse ponto. 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 outro colega” pode trazer nova luz às dificuldades. Claro que sempre tomando o cuidado de não delegar tarefas.
| Porcos e Galinhas  Até onde sei, a origem da fábula sobre o porco e a galinha perdeu-se no tempo, mas você pode encontrá-la recontada em vários locais da web, com pequenas variações. A história é mais ou menos assim: uma galinha e um porco viviam em uma fazenda. O fazendeiro era um homem muito bom e os dois decidiram que gostariam de fazer algo para retribuir tal bondade. A galinha surgiu com a ideia de presentear o fazendeiro com um apetitoso café da manhã. O porco ficou logo interessado e perguntou o que cada um deveria fazer. A galinha, ciente do pouco que ambos tinham a oferecer, propôs colaborar com alguns ovos. O porco, humilde, perguntou: “e eu, com que posso contribuir?”. A galinha respondeu: “humm… ovos caem muito bem com bacon!”. O porco, então, concordou, mas antes disse: “tudo bem, mas, enquanto você está fazendo uma contribuição, eu é que estou realmente comprometido com o presente…”. Assim, no Scrum, os porcos são todos os desenvolvedores, projetistas e testadores realmente comprometidos com o trabalho. As galinhas são todos os demais que contribuem intelectualmente com o projeto, mas não estão comprometidos com seu resultado. |
