As Armadilhas do Scrum Mecânico

Vanessa Franchi
6 min readJan 28, 2021
Fonte: blog da Concrete

Por Thiago Lima e Vanessa Franchi

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, conseguimos 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:

Fonte: https://media-exp1.licdn.com/dms/image/C4D12AQECM4FrVUS1PA/article-inline_image-shrink_1000_1488/0/1528581793068?e=1617235200&v=beta&t=2DO5IpTWYmUygaWOUdzruHYeXhkmti2gzpq663EeW5c

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

Resolvemos escrever este post 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.

Fonte: https://media-exp1.licdn.com/dms/image/C4D12AQEEuEdaXUzkAw/article-inline_image-shrink_1000_1488/0/1528581861408?e=1617235200&v=beta&t=9-Ru82SFI7aYz5_TThtNkeFrzy2rBOk3wd9Sy4vWUXE

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.

Fonte: https://media-exp1.licdn.com/dms/image/C4D12AQEhny8pRzeI6w/article-inline_image-shrink_1000_1488/0/1528581908492?e=1617235200&v=beta&t=dmnDwNPQrKqYuwrQPxJaj8Kfn_7ODL02Vsdsw-sv6Nk

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.

Fonte: https://media-exp1.licdn.com/dms/image/C4D12AQFLdzzJ8YJveg/article-inline_image-shrink_1000_1488/0/1528582092124?e=1617235200&v=beta&t=kAuhBAky_MIJxdYgrRkpu-dx2cba6UJ6m-D_UF1LRXU

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.

Fonte: http://nobelcoaching.com/wp-content/uploads/2017/08/overprotective-parents.jpg

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.

Fonte: https://media-exp1.licdn.com/dms/image/C4D12AQHbmDahKwLAvA/article-inline_image-shrink_1000_1488/0/1528582233036?e=1617235200&v=beta&t=anqh4P75HoRFLN2ZEBK-6QNU56Kxsvs6Lm-Zu3enuMc

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.

Artigo originalmente publicado em: https://concrete.com.br/2018/06/06/as-armadilhas-do-scrum-mecanico/

--

--

Vanessa Franchi

A truly Agile enthusiast! Trilingual Agile & Delivery Specialist.