O Scrum é um framework baseado em um processo empírico, construído em cima de três pilares: transparência, inspeção e adaptação. Transparência em nossas relações de trabalho, inspeção para checarmos se o que foi feito gerou valor e adaptação para melhorarmos o que fizemos. Se estivermos sempre de olho na melhoria contínua, conseguiremos estar mais aderentes aos objetivos de negócio.

Você já deve ter ouvido essa definição algumas vezes, mas o Scrum de verdade é muito mais do que isso. Erra quem encara o Scrum como um processo, pois mais importante do que pensar em um framework, é ter um mindset. Afinal, compreender as origens nos dá suporte para o dia a dia e nos ajuda até a fazer ajustes ou concessões quando e se for necessário, pois o objetivo é sempre agregar valor às partes interessadas. Entender a essência do framework e do manifesto ágil nos dá uma visão mais abrangente e menos prescritiva.

Também vale muito entender e praticar os valores do Scrum, o que ajuda na execução de um framework mais vivo e, consequentemente, menos mecânico. A atualização do Scrum Guide – o guia do framework ágil Scrum de 2016 mostra os seguintes valores:

Um time com coragem, foco, comprometimento, respeito e abertura prospera, atinge a auto-organização e a alta performance.

Resolvemos escrever este artigo porque, durante nossa caminhada como Scrum Masters, temos percebido que muitas vezes quando levamos muito ao pé da letra o Scrum Guide, acabamos caindo em algumas armadilhas, que podem nos fazer deixar em segundo plano o que é mais importante no mundo da agilidade: a entrega de valor. Vamos, então, a exemplos de situações em que isso acontece e a dicas de como podemos agir nesses casos.

Cenário 1

No meio de uma discussão calorosa, durante o feedback sobre o incremento entregue na reunião de Revisão da Sprint, eis que o Scrum Master solta: “o timebox acaba em 20 minutos!”.

Problema: interromper uma discussão no meio de um feedback de um stakeholder.

Solução: em um domínio caótico, é papel do Scrum Master agir para ajudar os envolvidos na discussão chegarem a um consenso (seja ensinando a concretizar o pensamento em forma de desenho na parede ou usando técnicas de consenso), ou até mesmo tomar a posse da discussão para fazer com que o time chegue a uma conclusão dentro do timebox pré-definido. O melhor, neste caso, é escolher outro momento para, com cautela, compartilhar com o Scrum Team os riscos de expirar a duração da meeting e ficarmos sem solução.

Cenário 2

Numa reunião de Retrospectiva da Sprint, o Scrum Master resolve passar por todos os pontos: positivos e negativos, sem levar em conta o cansaço da equipe de Scrum.

Problema: não estar atento à atenção e à resposta da equipe aos estímulos desse evento do Scrum.

Solução: lembrar-se de que, no Scrum, as pessoas e os relacionamentos são mais importantes que os processos. Por isso, estar atento ao cansaço do time é mais importante do que passar por todos os pontos do board de Retrospectiva. Uma dica é sugerir pausas ou então, por exemplo, o uso da técnica Pomodoro, em que se trabalha 25 minutos e se descansa de 3 a 5 minutos, alternada e indefinidamente.

Cenário 3

Em uma reunião de Planejamento da Sprint, o Scrum Master define que, já que a Sprint é de quatro semanas, a duração da reunião deve ser de oito horas.

Problemas: de acordo com o Scrum Guide, para uma Sprint de quatro semanas, o timebox recomendado é de oito horas, o que significa que a reunião pode durar de zero a oito horas. Apesar de o Scrum Master ter o ônus sobre os processos de Scrum, ele não deve impor nada.

Solução: o Scrum Master deve tentar otimizar, o máximo que puder, a reunião de Planejamento da Sprint de forma que tudo o que será feito na próxima Sprint fique claro para o time de desenvolvimento; que as discussões sejam levadas a um acordo mútuo e que não haja interrupções por assuntos extra-Time de Scrum. Isso evita que a reunião fique muito longa e maçante. O ideal seria que as oito horas não precisem ser usadas, uma vez que essa é a duração máxima para uma Sprint de um mês.

Cenário 4

O Scrum Master define que, numa Sprint de quatro semanas (160 horas úteis), 16 horas têm de ser dedicadas ao Refinamento do Backlog.

Problema: o Scrum Guide diz que, apesar de o refinamento do backlog não ser um evento oficial do framework, é recomendado porque ajuda a tornar a Reunião de Planejamento da Sprint mais produtiva, pois muito já terá sido discutido até que ela chegue; entretanto, 10% é o máximo recomendado que time de desenvolvimento deve se dedicar a essa reunião, e é o time quem deve reportar a necessidade ou não de todo o tempo ser utilizado.

Solução: não é porque no Scrum Guide o Refinamento de Backlog é mencionado que ele tem que ser formalmente realizado, mesmo porque o guia deixa claro que o refinamento não é um evento oficial do Scrum. O ideal é que o time de desenvolvimento identifique a necessidade ou não de o Backlog ser refinado e que o Scrum Master somente facilite essa reunião, cujo ônus é do Product Owner. Como facilitador do processo, o Scrum Master pode explicar aos devs a importância de ter um Backlog refinado para, por exemplo, otimizar a reunião de planejamento da Sprint.

Cenário 5

Ao ver que o time de desenvolvimento tem uma dificuldade para falar com alguém do cliente, imediatamente interferir tentando resolver.

Problema: ao tentar resolver os problemas do time de desenvolvimento – sem querer – o Scrum Master acaba desencorajando o time a fazer isso sozinho. Isso pode criar uma relação de dependência em que os Devs passam a crer que precisam do SM para tudo.

Solução: o Scrum Master só precisa garantir que está incentivando o time de desenvolvimento a procurá-lo caso sua dificuldade se transforme em um impedimento, ou seja, ele só interfere na solução de um problema após os Devs terem tentado de tudo e, idealmente, quando fosse chamado. O SM precisa criar equipes de alta performance que se auto-gerenciam e organizam para entregar valor, ainda que na sua ausência.

Em síntese, é essencial que nós, enquanto Scrum Masters, tenhamos pleno conhecimento do nosso maior guia de referência, que é o Scrum Guide, a fim de que possamos exercer as competências inerentes ao nosso papel.

Contudo, se não analisarmos cada cenário individualmente e não observarmos, com atenção, o nosso redor, corremos o alto risco de aplicar nossos conhecimentos de uma forma que não gera valor aos envolvidos, o que nos afasta do principal objetivo do framework.

Levar em conta o mindset ágil nos ajuda a compreender a essência do Scrum e evita que o apliquemos mecanicamente. Como Scrum Masters, devemos ajudar o time a entender e praticar os valores do Scrum para que, com a melhoria contínua, consigamos atingir melhores resultados. Não somos nós que devemos nos adequar ao nosso guia, mas nosso guia que deve ser adaptado por nós para a atual realidade, sempre levando em conta os três pilares do processo empírico.

Ficou alguma dúvida ou tem algo a dizer? Aproveite os campos abaixo e até a próxima!

***

Este artigo foi escrito em colaboração com Vanessa Franchi e foi publicado originalmente em: https://www.concrete.com.br/2018/06/06/as-armadilhas-do-scrum-mecanico/