9 Erros que o Scrum ajuda a resolver

O Scrum é um framework (uma grade, esqueleto,  estrutura) para construção de processos para execução de projetos. Ele não é uma metodologia, porque não define métodos. Também não é um processo, porque não precisa ser seguido exatamente como foi concebido. (Leia sobre as definições de metodologia, processo, procedimento, padrão etc)

Por ser totalmente adaptável, o Scrum pode ser um paraíso ou um inferno na “vida” de seus projetos. Isso porque ele é baseado em princípios (transparência, inspeção e adaptação) que geralmente são esquecidos na hora de construir um processo. Aí surgem anomalias como projetos em que o PO é o SM, projetos sem reuniões diárias, sem nenhum tipo de quadro de acompanhamento e até projetos com sprints “eternas”. (Leia mais sobre isso no post “10 erros na implantação de Scrum que você não quer cometer“)

Mas se os princípios forem seguidos corretamente e o fluxo do Scrum for compreendido “na real”, ele pode resolver problemas clássicos da gestão de projetos, sobretudo dos projetos de TI. Vamos a eles:

Erro #1 – Não entender e nem delimitar o escopo do projeto

A maior parte dos problemas dos projetos está relacionada ao Escopo. E o escopo vem do levantamento (identificação, entendimento e descrição) dos requisitos. Isso acontece por motivos como: pouco tempo, técnica inadequada, indefinições nos processos de negócios, mudanças etc.

Resposta: O scrum resolve isso de forma sistemática. Define uma “lista de desejos” priorizada e aprofunda apenas os requisitos que forem importantes, pouco antes de executá-los. Não carece de aprovações, pois quem executa essas definições é o PO e ele já é o representante máximo do cliente. E se houver mudanças, basta repriorizar a lista.

Erro #2- Levar “tempo demais” desenvolvendo o produto

O cliente recebe uma equipe sorridente de consultores, que anotam, tiram fotos e levam modelos de relatório e só encontra com eles novamente meses depois! Isso aumenta bastante a ansiedade do cliente, que provavelmente está pagando todo mês a conta do desenvolvimento.

Resposta: A participação a cada Sprint “alivia a ansiedade” do cliente, permitindo que redirecione a construção do produto, se for o caso.

Erro #3 – Não obter aprovações parciais das entregas ao longo do projeto

Muitos projetos ainda seguem o velho estereótipo da engenharia, os gênios se fecham numa sala e saem de lá com a solução (tabajara) para todos os problemas da humanidade.

Acontece que ao final do projeto percebem que a solução mágica não era nada do que o cliente queria. O famoso “canhão para matar formiga”.

Resposta: No Scrum além do PO ser O PRÓPRIO cliente, existe ao final de cada Sprint, uma Reunião de Revisão. Como a Sprint é um período curto e fixo (timebox), o cliente tem a chance de aprovar entregas parciais ao longo de todo o projeto, aumentando assim a probabilidade de sucesso.

Erro #4 – Não conseguir reagir a mudanças drásticas rapidamente

Certa vez participei de um projeto de 2 anos que a cada 3 meses mudava suas regras de negócio. As regras mudavam por diversos motivos como: novas tecnologias, leis, definições de negócio etc.

A equipe do projeto seguia um processo rígido de aprovações, em que era necessário seguir o C.I.M.  (Controle Integrado de Mudanças) do PMBOK. Uma mudança precisava ser descrita e aguardar na fila para ser julgada por um comitê que nem sempre a aprovava, à revelia da vontade do cliente.

Resposta: A cada sprint são priorizados os “desejos” que serão desenvolvidos. Se precisar incluir alterações nos “desejos” antigos, eles são simplesmente vistos como novos desejos entrando na “linha de produção”.  Cabe ao PO entender que se precisa alterar “desejos” antigos, não terá novos. E com isso, gerenciar as expectativas da empresa cliente.

Erro #5 – Não ter uma visão realista do trabalho completado

Ainda é um erro recorrente organizar a execução dos projetos de forma a terminar “atividades” e não “entregas”. Por mais que o PMI perca a voz pregando o uso da EAP, muita gente constroi EAPs por fase ou simplesmente exclui do escopo do projeto entregas importantes para o cliente.

Dessa forma, quando a equipe termina de executar o trabalho sempre acaba faltando alguma coisa.

Resposta: Para o Scrum isso é muito simples. Primeiro, o PO determina a “lista de desejos”. Segundo, existe um conceito importantíssimo que é a Definição de Pronto (Definition of Done), com isso tem-se claramente antes de começar o “jogo”, o que significa estar “pronto. (Leia mais em “Como saber se a entrega está completa mesmo?“)

Erro #6 – Deixar problemas e impedimentos para depois

Infelizmente já vi muitas vezes acontecer da equipe do projeto decidir sozinha que um problema, uma dificuldade qualquer, deve ser deixada para uma “segunda fase” para viabilizar o cumprimento do prazo do projeto.

Isso gera projetos “eternos”  e produtos inúteis. Mas não apenas isso, gera equipes desanimadas por estarem realizando os trabalhos “de qualquer jeito”. Também permite que problemas estruturais continuem acontecendo por longos períodos, em outros projetos.

Resposta: No Scrum há duas ferramentas que podem ajudar a solucionar esse problema. A primera, é a obrigatoriedade que o SM tem de direcionar soluções para os impedimentos em até 1h após a Daily Meeting. A segunda é a Reunião de Retrospectiva, em que toda equipe discute os pontos fortes e fracos da Sprint (ciclo PDCA).

Erro #7 – Não comunicar andamento, sucesso e fracasso das atividades do projeto

É aquela velha história, só o GP tem MS-Project!! rs. Com isso,  manda “ppts” como relatório de status, que nunca tem a fotografia atual do projeto. Os problemas, ele tenta resolver antes da reunião para não fazer “papelão” E até adota posturas antiéticas como a de esconder informações, se estiver em um ambiente muito hostil.

Resposta: No Scrum as coisas são simples = TRANSPARÊNCIA. Reuniões diárias, status report está “colado na parede” para quem quiser ver. E é estimulado que as pessoas tragam os problemas para discussão aberta e colaborativa.

Erro #8 – Não seguir um fluxo formal de aprovação de mudanças

Mudanças não-aprovadas são reprováveis, pois geram custo e não trazem lucro. Também podem impactar em outras “partes” do produto, gerando um Frankestein. Segundo o PMBOK, deve-se seguir um C.I.M para garantir que todos os impactos foram observados, mas isso leva um tempo que nem sempre é viável. Com isso o GP “assume riscos” e tipicamente acaba perdendo o controle da documentação (e com ela, do rumo do projeto).

Resposta: No Scrum  há a preciosa regra de “só pode haver mudanças ao final de cada Sprint”. Com isso a timebox é preservada e-a equipe pode trabalhar “em paz”. Se houver uma urgência que torne impossível esperar, pode-se negociar com o PO o cancelamento da Sprint e replanejar uma nova (questão de horas).

Erro #9 – Escopo fixo e prazo eterno

O problema do Escopo fixo é o fato de ser fixo. Vira um jogo de negociação “toma lá, dá cá” e acaba gerando o típico diálogo:

_ Tempo e o custo não podem mudar (Gerente)

_ Ok e o escopo? (Equipe)

_ Também não. (Gerente)

Então todos juntos fecham os olhos fingem estimar um prazo, que sabem que não será cumprido. Pois quando se planeja algo abstrato como a construção de um produto, fica difícil dizer exatamente o tempo que vai levar. Com isso acaba-se estimulando a Lei de Parkinson e as estimativas “chute”.

Resposta: O scrum estimula o uso de  estimativas não lineares e monitora o desempenho da equipe aceitando as variações como parte do processo de execução.  O escopo é aberto, prazo e custo podem ser fixos.

Eli Rodrigues