Existem distintas formas de se acompanhar o andamento de um projeto. Praticamente cada modelo de gerenciamento sugere sua própria forma de seguir de perto como anda o desenvolvimento das tarefas. Gráfico de Gantt, gráfico focado em produtividade do Kanban e etc… são apenas algunas exemplos do que é utilizado hoje no acompanhamento de projetos em TI. Acredito que a maioria dos leitores esteja acostumada e familiarizada com os gráficos de Gantt. Apesar de serem bastante difundidos e utilizados mundo afora, pessoalmente julgo que esse método de acompanhamento funciona muito bem quando o foco são datas de entrega ou planejamentos de longo prazo. Quando focamos no acompanhamento da produtividade de uma equipe no dia-a-dia, o gráfico burndown do SCRUM e o baseado na produtividade do Kanban se mostram muito mais robustos e evidentes.

Para este post, vou focar no gráfico de burndown. Neste gráfico, o eixo horizontal representa os dias de duração de uma sprint e o eixo vertical a quantidade de tarefas que ainda não foram cumpridas dentro do espaço de tempo determinado. Dessa forma, todos os dias a gerência da equipe pode verificar a produtividade do dia anterior e qual a meta que precisa ser alcançada para que todas as tarefas que ainda restam consigam ser finalizadas no prazo.

Acredito que a maior dificuldade para a equipe de gestão de um projeto SCRUM é saber interpretar os dados que lhe são mostrados no gráfico e como repassar essas informações preciosas para o product owner do projeto ou o cliente em questão. Sprint passada enfrentei um problema similar. Algumas alterações no burndown não foram bem interpretadas pelo product owner do projeto. Percebi que, apesar de atingir muito bem seu objetivo, algum tipo de informação relevante estava faltando ali. É como se a informação estivesse na frente dos nossos olhos, mas a nossa forma de pensar estivesse bloqueando o real entendimento.

Decidi então adicionar uma nova curva ao burndown. Ao invés de mostrar somente a curva da quantidade de tarefas “queimadas” durante os dias da sprint, coloquei também uma nova curva onde apresentávamos a evolução do número total de tarefas. Pode parecer estranho para alguns, mas no SCRUM as tarefas que devem ser executadas em cada iteração podem variar de acordo com a demanda. Durante uma sprint, podemos tanto remover como adicionar novas tarefas e justamente essa visibilidade foi a que senti que estava faltando no burndown do meu projeto. Uma descida mais suave no gráfico de produtividade não significa que a equipe teve uma baixa produtividade, mas sim a influência do incremento do número de tarefas a serem executadas naquele período.

Esses dias estive refletindo bastante sobre como deve se portar um líder de equipe diante das mais diferentes situações. Qual deve ser a postura de um líder criativo? Deve ser inspirador ou deve focar em mostrar que possui a situação sobre controle?

Decidi procurar referências em livros e uma amiga me indicou um bastante interessante. Se chama “The Leader’s Guide to Lateral Thinkin Skills“. O livro faz um paralelo bastante interessante sobre como se porta um líder clássico e um líder que está preocupado com inovação e com a disseminação do pensamento criativo. Dentre as principais diferenças entre esses dois tipos de líderes, vou citar algumas que me chamaram a atenção.

Líder clássico: Dirige, desprende maior tempo em questões operacionais do dia-a-dia do que em novas estratégias, dá a direção e as ordens, desmerece idéias e iniciativas sem prévia análise, fechado à críticas, etc…

Líder criativo: Inspira, desprender maior tempo à procura de novas estratégias e parceiros, faz perguntas, pede sugestões e delega, encoraja todos tipos de iniciativas e frequentemente implementa idéias, encoraja críticas construtivas, etc…

Posto isto, fica evidente que o líder criativo possui um perfil mais vanguardista e está mais inclinado a aceitar e lidar melhor com os riscos chegando ao patamar onde o risco torna-se um aliado à inovação. O resultado desse relacionamento tão peculiar com os riscos (lembrando aqui a importância de ter a maioria deles sobre controle e identificados), o líder criativo aposta pela quebra de regras para promover a inovação dentro da sua equipe. Pra algumas pessoas, esse tema não é novidade, principalmente quem mergulhou de fato no mundo das metodologias ágeis, mas eu acho que é uma temática que deve ser sempre reiterada e que é crucial nos projetos em que se deseja inovar.

A partir da quebra de regras de um negócio foi que se conseguiu um maior nível de inovação em determinado setor. Um bom exercício para tal é tentar identificar todas as regras intrínsecas ao seu modelo de negócio. Após haver mapeado um número razoável, pondere quais das regras parecem ser descartáveis e tente jogar com esse modelo retirando-a do contexto. Um bom exemplo para tal foi executado pela Heinz, a fabricante de ketchups. Enquanto a maioria dos molhos de tomate da concorrência nos EUA possuíam uma consistência mais líquida, o molho Heinz era mais espesso e exigia que o usuário tivesse que bater no fundo da lata pra conseguir extrair o conteúdo da embalagem. Havendo identificado essa particularidade, ao invés de mudar a fórmula do seu molho, a Heinz decidiu investir em uma estratégia de marketing onde se definia que o bom molho de tomate era o espesso. A campanha foi um sucesso e a Heinz hoje é uma das líderes no setor.

Existem N outros exemplos onde a quebra de regras foi crucial para a inovação. Será que vocês arriscam dar mais alguns exemplos? Como funciona o jogo de regras na sua equipe? Comenta aí!

Recentemente tenho quebrado a cabeça em como melhorar as retrospectivas em meu projeto. Após aproximadamente 2 anos, as retrospectivas tendem ao tédio e o time não consegue pensar em fatos diferentes de problemas com infra-estrutura e eventuais horas-extras.

Pensando nisso, decidi dar uma olhada no que está sendo feito em retrospectivas para tentar obter resultados diferentes e um plano de ação mais conciso. @estherderby é uma das referências quando se fala de Agile Retrospectives e no vídeo abaixo ela e uma companheira deram uma boa apresentação em como montar uma reunião de retrospectiva e o que fazer se você espera ter um resultado diferente. Mudar o foco é a palavra chave. Espero que vocês gostem.

Recently I have been struggling on how to improve Agile Retrospectives on my project. After nearly 2 years, retrospectives tend to boredom and the team cannot think of different facts otherwise than bad infrastructure and sparse extra working hours.

Thinking about that, I decided to have a look on what else I could be doing in a retrospective so that I could have a different output and a more concise action plan. @estherderby is one of the references when talking about Agile Retrospectives and in the video below she and a colleague give a nice presentation on how to set up a retrospective and what to do if you expec.t to have a different output. Changing the focus is the key point. I hope you guys enjoy.

As metodologias ágeis de gestão de projeto não estabelecem uma regra para o levantamento de requisitos no começo de cada iteração. De acordo com o SCRUM após as reuniões de Sprint Planning a equipe deve possuir um Sprint Backlog estimado e priorizado em conformidade com o que o Product Owner e a equipe do projeto acreditam que deve ser executado na Sprint atual. Durante essas reuniões, o time inteiro e o Product Owner são incitados a tirar dúvidas e levantar mais detalhes em relação a cada User Story que foi selecionada como escopo da Sprint, porém não há nenhuma recomendação sobre formas de propagar requisitos ou até mesmo descrevê-los.

Como os próprios métodos ágeis pregam, devemos tentar fugir ao máximo de documentos e artefatos que pouco agregam ao time. Se no seu caso, as reuniões de Sprint Planning e conferências com o Product Owner são suficientes então nem continue lendo esse post. A nossa proposta é sugerir formas de manter esses requisitos na mente dos desenvolvedores e também trabalhar mais a fundo essas propostas, de forma a estimular a criatividade da própria equipe e disseminar o conhecimento dos requisitos.

A primeira técnica que já utilizei foi o famoso gravador de voz. Durante as reuniões com o cliente, levávamos um gravador MP3 para registrar todos os momentos com o Product Owner. O arquivo era posteriormente distribuído através do repositório da projeto. Os desenvolvedores e o Scrum Master sempre poderiam revisitar o arquivo de áudio e esclarecer possíveis dúvidas que surgem após um determinado tempo.

A segunda técnica consiste em utilizar um membro da equipe para, após as reuniões de planning, criar uma apresentação com uma visão geral sobre cada requisito/user story e seus impactos. A grande vantagem dessa abordagem é a subsequente reunião que é feita após a definição desses requisitos. Todos os membros da equipe são encorajados a refinar os requisitos e a discutir de forma criativa as soluções que foram dadas aos problemas. Inclusive pudemos observar que a participação de engenheiros de teste foi bastante útil uma vez que eles são capazes de antecipar com maior critérios os fluxos secundários e os impactos de cada User Story no que já foi desenvolvido.

Existem várias outras possibilidades como o uso de vídeos, combinação de ténicas acima, uso de cartões e etc… O que realmente importa é garantir que  a todo momento todos os membros da equipe têm claro o que devem fazer e o que deve ser coberto ou não por cada estória a.k.a definição de pronto.