Scrum: inversamente proporcional para cada empresa

Ao contrário do que muitos acreditam o Scrum não é um processo padronizado onde metodicamente você segue uma série de etapas sequenciais e que vão garantir que você produza no prazo e no orçamento, um produto de alta qualidade que encanta os seus clientes.

O Scrum é um framework para organizar e gerenciar trabalhos complexos, tal como projetos de desenvolvimento de software. Portanto, o framework Scrum é um conjunto de valores, princípios e práticas que fornecem a base para que a sua empresa adicione suas práticas particulares de gestão e que sejam relevantes para a realidade do seu negócio.

O resultado será uma versão de Scrum que é exclusivamente sua!

Mas, para melhor entender este conceito, imagine que o framework seja como a fundação e as paredes de um edifício. Você não pode ignorar ou mudar fundamentalmente um valor, princípio ou prática sem o risco de colapso. O que você pode fazer, porém, é personalizar o interior da estrutura (do Scrum), acrescentando artefatos e recursos até que você tenha e um processo que funciona para sua empresa.

Pilares do Scrum

Os três pilares que sustentam o funcionamento eficiente do Scrum são a transparência, a inspeção e a adaptação.

  1. Transparência

Todo projeto desenvolvido deve partir de um planejamento detalhado, no qual são estabelecidos os objetivos específicos a serem alcançados. O ponto aqui é fornecer a todos os membros da equipe informações para nortear seu trabalho. Eles devem estar alinhados e, por isso, a transparência desempenha um papel fundamental no processo.

Vale destacar importância de manter essas informações em um ambiente de fácil acesso para consulta.

  2. Inspeção

Os processos de inspeção compõem o monitoramento que os gestores devem promover. Na prática, o objetivo é manter o controle sobre o andamento das atividades, garantindo que os objetivos estejam sendo alcançados e que os avanços ocorram no tempo previsto.

Um ponto que merece atenção é a frequência e a profundidade dessas inspeções. Afinal, elas não podem representar um empecilho que gere atrasos no projeto. A burocracia deve ser a menor possível.

  3. Adaptação

Um dos grandes diferenciais do Scrum são as chamadas iterações incrementais. Trata-se de implementações que são feitas ao longo de todo o processo, gerando melhorias e otimizações no produto. Isso pode acontecer de diferentes formas.

Caso uma inspeção identifique que algo não está de acordo com os objetivos estabelecidos, uma adaptação pode ser feita. No entanto, não é só isso. No Scrum, o cliente passa a ter contato mais direto com o desenvolvimento para explicar mais detalhadamente suas necessidades e aprovar cada nova implementação.

Logo, é possível que surjam novas ideias e oportunidades de melhoria ao longo do processo de criação. Isso demonstra a flexibilidade do Scrum: se os objetivos mudam ao longo do desenvolvimento, a equipe é capaz de se adaptar rapidamente para atender a essa nova demanda.

Planejamento: o calcanhar de Aquiles do Scrum

Dentro desse framework o principal pilar no meu ponto de vista é o planejamento. Nem sempre a Sprint Planning é produtiva nas empresas e isso ocorre porque é muito fácil perder o foco e a eficiência nesse encontro porque é, sem dúvida, o rito mais maçante do Scrum. Por isso, é necessário fazer de maneira assertiva para não desperdiçarmos o tempo do time.

É fundamental e imprescindível que todo o time de desenvolvedores esteja disponível para participar da Sprint Planning. Ausências não eximem os ausentes da responsabilidade do que for acordado nesta reunião.

Além disso, é importante que todos os desenvolvedores sejam capazes de dizer o quanto estarão disponíveis para a próxima Sprint. Jamais acredite que 100% dos membros do time estarão disponíveis 100% do tempo e não se esqueça que novos membros podem entrar no time e que demoram a se adaptar.

Em geral, assumir uma capacidade de produção de 80% do total de horas trabalhadas é uma prática aceitável para cobrir possíveis ausências não previstas (doenças, atrasos diversos, detalhes não previstos, bugs urgentes etc).

Para que a Sprint seja minimamente bem-sucedida, os desenvolvedores jamais devem superestimar sua capacidade de produzir. Para cada tarefa a ser estimada, por qualquer técnica escolhida, cada detalhe que possa afetar a capacidade do time de entregar aquela tarefa deve ser analisado.

Ter uma definição de pronto bem definida ajuda bastante, pois dá uma noção mais clara de todas etapas que cada tarefa deverá percorrer para ser entregue de fato.

Falhas comuns

Uma falha comum na definição do escopo e comprometimento com tarefas é ignorar o débito técnico. O time de desenvolvimento tem de estar ciente de que em torno de 25% do seu tempo estará fazendo correções e ajustes.

Se o time ignorar o débito técnico, seja não deixando esta margem ou qualquer outra, mais cedo ou mais tarde terá problemas técnicos e sua produção cairá em sprints futuras.

Outra falha comum é na definição de tarefas. Jamais detalhe com uma granularidade muito fina o que terá de ser feito. Como a responsabilidade dos detalhes de implementação cabe aos desenvolvedores, não há porque discutir e especificar isso abertamente dentro da Sprint Planning. Nada impede, no entanto, que os desenvolvedores se reúnam após a Planning para uma reunião técnica de detalhamento.

Outra armadilha recorrente é subestimar a importância desse planejamento colaborativo e democrático. Alguns times nomeiam um líder para tomar as decisões por todos, desconsiderando a importância de suas opiniões individuais no processo de planejamento.

Conclusão nua e crua

Se todos tiverem ciência do que, porque, como e em quanto tempo serão realizadas as atividades o objetivo de uma Sprint poderá finalmente ser atingido com sucesso. E com isso seu framework Scrum estará validado, bem com a missão de otimizar processos e manter a empresa competitiva no mercado também será atendida.