Olá, pessoal, tudo bem com vocês? Faz um bom tempo que eu não escrevo um artigo por aqui e queria agradecer aos e-mails elogiando meus artigos e os pedidos de novos.

Como todos bem sabem, as Metodologias Ágeis são o novo farol para os projetos de software. Particularmente, sou fã do Ágil e procuro aplicar seus conceitos diariamente.

Puxando todo esse movimento, eis que temos o Scrum. Acredito que, ao ler este artigo, você já tenha conhecimento do Scrum e de como ele funciona.

O que normalmente vejo em algumas empresas e em alguns comentários é que muitas pessoas não utilizam o Scrum com todos seus papéis, etapas e processos, o que não deve ser considerado totalmente errado, porque a flexibilidade é aliada da agilidade, e só vai ser ágil quando você se sentir confortável em usar a metodologia (mas cuidado para não virar bagunça!).

Então chegamos ao dilema: não sigo todos os processos do Scrum, será que minha equipe é ágil?

A resposta é SIM, meu amigo, e para provar isso temos o ScrumBut. Mas o que seria isso?

Sabe quando alguém pergunta a você se sua equipe utiliza Scrum, e você diz: “usamos Scrum, mas…”

É exatamente isso, o processo adaptativo da metodologia tem nome e sobrenome.

Segundo o Scrum.org, temos a seguinte definição:

ScrumBut existe pela razão de as equipes não poderem tirar o máximo proveito do Scrum para resolver seus problemas e perceber os benefícios do desenvolvimento de produtos utilizando Scrum. Cada papel, regra, e timebox do Scrum é projetado para proporcionar os benefícios desejados e resolver os problemas recorrentes previsíveis. ScrumBut significa que o Scrum expôs uma disfunção que está contribuindo para o problema, mas é muito difícil de corrigir. ScrumBut mantém o problema ao modificar o Scrum para torná-lo invisível, para que, assim, a disfunção não seja mais uma pedra no sapato da equipe.

Exemplos ScrumBut [Minhas observações]

“Nós usamos o Scrum, mas com ter uma reunião diária sobre Scrum todos os dias é muito em cima, por isso só temos uma por semana”. [Cuidado com esse tipo de abordagem. A reunião diária é importantíssima para um feedback preciso e uma resolução de problemas de maneira rápida. É preciso muita maturidade da equipe para deixar esse ponto de lado.]

“Nós usamos o Scrum, mas retrospectivas são um desperdício de tempo, de modo que não é necessário fazê-las”. [Normalmente escuto isso também, mas o que se percebe é que a retrospectiva não é feita como deveria. É um momento de rever o que se fez de errado e onde não errar.]

“Nós usamos o Scrum, mas não podemos construir um pedaço de funcionalidade em um mês, porque as nossas Sprints são de seis semanas de duração”.

“Nós usamos o Scrum, mas às vezes nossos gestores nos dão tarefas extras porque nem sempre têm tempo para entender a nossa definição de feito”. [A antecipação de tarefas deve ser uma coisa organizada. Se o time acaba as tarefas muito antes do que foi definido, é melhor ver a raiz do problema, ou seja, a estimativa de cada item do Backlog.]

Às vezes, as organizações querem fazer mudanças de curto prazo relacionadas a Scrum para dar-lhes tempo para corrigir deficiências. Por exemplo, a definição de “feito” pode não existir, inicialmente, no teste de regressão e nos testes de desempenho, porque vai demorar vários meses para desenvolver testes automatizados. Para esses meses, a transparência fica comprometida, mas a definição de “feito” volta ser incluída tão rapidamente quanto possível.

É isso aí, pessoal, espero que vocês tenham gostado e em breve escreverei mais artigos sobre o mundo Ágil.