Concrete Logo
Hamburger button

As Armadilhas do Scrum Mecânico

  • Blog
  • 6 de Junho de 2018

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: http://www.fabiocruz.com.br/wp-content/uploads/2016/09/valores-scrum.gif

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://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTO6Oa-HpDDZZzOvoSzm-5yX0xrell3IJREcBoE6eSZgEuOsyNM

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://www.napratica.org.br/pontos-fortes-e-fracos/

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://www.jornaldoempreendedor.com.br/wp-content/uploads/2013/12/estress1.jpg

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: https://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://image.slidesharecdn.com/competnciasdoscrummasterdevops-170402231132/95/as-8-competncias-do-scrum-master-6-638.jpg?cb=1491503577

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!

A agilidade está presente na Concrete desde o início, o que levou a empresa, hoje parte da Accenture Technology, a se tornar referência na transformação digital dos clientes. Criamos produtos digitais inovadores justamente por sermos uma consultoria de produtos, não apenas de tecnologia. No capítulo de Agilidade, a missão é capacitar os agilistas a maximizarem a entrega de valor, de maneira iterativa e incremental. Quer trabalhar com os melhores? Acesse: concrete.com.br/vagas