Lições de um Scrum Master iniciante

Tudo começou com um desafio: precisávamos gerenciar nossos projetos com agilidade, sem muita formalidade e de uma forma que qualquer um pudesse acompanhar a qualquer momento o que estava acontecendo . Foi aí que sugeri o Scrum.

Não, não tenho experiências anteriores com Métodos Ágeis. Não sou profissional de Tecnologia da Informação, tampouco trabalho com Desenvolvimento de Software. Sou um cara de Processos de Negócios, principalmente de Manufatura. E apesar de toda a vivência com Projetos, nunca havia me aprofundado a respeito de Scrum até aquele momento.

Desafio aceito, lá fui eu colocar em prática o pouco que sabia: peguei um rolo de papel kraft, alguns post-its e eis que já tínhamos nosso primeiro Task Board.

Evolução do nosso Task Board (1º Semestre de 2017)

Aos poucos fomos aprendendo e, principalmente, compreendendo mais sobre o Scrum. Ensinamos o Time, engajamos as pessoas, aperfeiçoamos nossas técnicas e ferramentas. E não é que gostei de tudo isso!? Mas apesar de estar trabalhando com Scrum já há alguns meses, de todas as leituras, das horas de estudo e de ter obtido o nobre título de “Mestre” em Scrum, ainda me considero um iniciante (pelo menos no exato momento em que escrevo este artigo).

Se você caiu aqui de paraquedas e não faz a menor ideia do que é Scrum, recomendo investir um pouquinho do seu tempo lendo o Scrum Guide, de Ken Schwaber e Jeff Sutherland (os pais do Scrum). Em apenas dezoito páginas você encontrará os Papéis, Eventos, Artefatos e as Regras que compõem o framework. É claro, existem inúmeras outras fontes à respeito em livros e na Internet, até mesmo outras variantes mais estruturadas (como o proposto pelo SBOK da SCRUMstudy). Já tem gente até mesmo falando do fim do Scrum!

Dito tudo isto, quero compartilhar com você (iniciante ou curioso) algumas lições que aprendi quando coloquei o Scrum em prática:

A primeira lição é: Não tente fazer Scrum. Faça Scrum. Mestre Yoda que me perdoe a paráfrase, mas é exatamente isso. Mesmo que você ainda não tenha todo o conhecimento, experiência ou recursos que considere necessários, VÁ LÁ E FAÇA! Não espere que todas as condições ideais de temperatura e pressão estejam propícias.

Quando você começa o Scrum com o pensamento de “vamos tentar” ao invés de “vamos fazer”, você desvia seu foco e energia para as consequências, se preocupando demais com o que pode ou vai acontecer e menos com o que deve ser feito. Ao se focar no agora, naquilo que você vai fazer hoje (que inclusive é uma das questões da Reunião Diária do Scrum), você dá uma passo de cada vez. Isso me lembra muito uma parte da filosofia de melhoria da Toyota, apresentada por Mike Rother no livro Toyota Kata, que faz a seguinte analogia sobre previsão x realidade:

Você definiu para onde que ir (Condição-Alvo), mas o caminho à frente entre aqui e lá é escuro. Você está segurando uma lanterna, mas ela só ilumina até uma certa distância na escuridão. Para ver adiante e iluminar os obstáculos escondidos na escuridão, você tem que dar um passo à frente (Página 121, Toyota Kata).

A mesma verdade se aplica ao Scrum: o caminho para o objetivo final (a Condição-Alvo) não é completamente claro, é uma zona cinza. Cada passo dado produz reações, porém, não sabemos de antemão que reações serão estas: problemas imprevistos, anomalias, suposições falsas e obstáculos, tanto no ambiente interno quanto no externo ao projeto. Enquanto avançamos, devemos estar atentos a cada uma destas reações, aprender com elas, realizar os ajustes necessários e seguir adiante. Não é tentativa e erro, é experimentação e aprendizado!

A segunda lição que aprendi foi a seguinte: não tente adaptar o Scrum logo de cara, pelo contrário, siga as regras. Pratique todos os Princípios (Controle de Processos Empírico, Auto-Organização, Colaboração, Priorização baseada em Valor, Time-Boxing e Desenvolvimento Iterativo), realize todos os Eventos (Planejamento da Sprint, Sprint, Reunião Diária, Revisão e Retrospectiva da Sprint), utilize todos os Artefatos (Product Backlog, Sprint Backlog e Incremento). Também não deixe de utilizar as Estórias, as Técnicas de Estimativas, os Critérios de Pronto e de Aceitação, o Burndown da Sprint e do Produto e a medição da Velocidade do Time.

Pode parecer MUITA coisa num primeiro momento, mas acredite, isso evitará sofrimentos e frustrações. Quer um exemplo? Quando começamos, nosso Sprint Burndown era medido em Quantidade de Tarefas, nada mais. Ou seja, todas as tarefas tinham o mesmo peso, não levando em consideração critérios de esforço, tempo e/ou complexidade. Resultado: pouquíssimas Sprints atingiam seus objetivos, Backlogs com tarefas faltantes e não conseguíamos medir a velocidade do Time. Quando entendemos isso e começamos a fazer direito, aí tudo mudou!

Tenha certeza: após praticar todo esse framework (muitas e muitas vezes), você terá o conhecimento original sobre o Scrum interiorizado e dominado, e com isso conseguirá comparar e adaptá-lo às particularidades da sua organização com muito mais eficácia.

A terceira e última lição que quero compartilhar com você é: o objetivo do Scrum é entregar a maior quantidade de Valor na menor quantidade de Tempo. Isso implica em mudar a perspectiva de como você enxerga as entregas do seu projeto. Outro exemplo: No começo do nosso aprendizado, trabalhávamos no projeto de um Dashboard de Informações Gerenciais, composto por três painéis. Para executá-los eram necessárias basicamente três tarefas: fazer as ETL’s dos Bancos de Dados, desenhar os painéis e por fim homologar com o Cliente. Pensamos “vamos fazer primeiro todas as ETL’s, depois todos os painéis e por último todas as homologações”. Pra quê!? Fizemos a primeira ETL (sucesso!), tivemos problemas na segunda (atraso!) e não conseguimos avançar com a terceira. Consequentemente todas as tarefas seguintes foram impactadas (em maior ou menor grau). Ao final da primeira Sprint o Cliente nos perguntou se já havia alguma coisa pronta que pudesse usar e avaliar. Ele não queria todo o Dashboard. Mas nós não sabíamos! Ele não havia nos falado sobre isso, tampouco perguntamos à respeito, pois nosso foco estava no Produto Final apenas.

Quando fizemos a Retrospectiva entendemos que estávamos trabalhando de modo errado. Geralmente enxergamos as Entregas na Perspectiva da Tarefa, procurando realizar tudo aquilo que é semelhante, que utilizará os mesmos métodos e recursos de uma vez só. Porém, quando trabalhamos assim, o que acontece? Temos várias tarefas concluídas, porém nada de valor para entregar ao Cliente. Estamos habituados a olhar apenas para o Produto Final, considerando que isso é sempre o mais importante para o Cliente.

Porém, quando enxergamos as Entregas na Perspectiva do Valor, focamos no Cliente, em ter algo pronto o mais rápido possível, e muito mais valioso do que um conjunto de tarefas, permitindo que a Entrega já possa ser utilizada, testada e até mesmo melhorada antes do final do projeto.

Espero que estas lições o ajudem em sua jornada com o Scrum. Um grande abraço e até a próxima!

Deixe um comentário com seu feedback! Gostou? Então compartilhe!