Eficiência em gestão de projetos ágeis usando Scrum

Eu tenho acompanhado o desenvolvimento software por mais de 15 anos e vi principalmente aqui no Brasil o crescimento dos projetos e a quantidade cada vez maior de pessoas trabalhando em atividades simultâneas e todos os conflitos relacionados para gerenciar um processo criativo, complexo e altamente dinâmico como é um projeto de desenvolvimento de software.

Quando inicio a falar da estratégia de gestão ágil com os clientes a primeira coisa que eles falam quando nunca tiveram contato é que o projeto não é gerenciável afinal não tem o papel formal de gerente para cuidar do projeto e que não confia nessas coisas meio descontroladas. É engraçado que essas história se repete várias vezes. A minha primeira abordagem é pedir para ele avaliar como está o caos gerenciado atual e começo apontando problemas no modelo tradicional atual como cronograma que não acaba nunca, falta de qualidade e todo retrabalho que nunca aparece no cronograma do gerente. É verdade você não encontra um gerente que aponte no centro de custo o prejuízo do projeto.

A visão de fábrica de software em cascata não funciona nem nos livros. Acabou o tempo em que se fazia os projetos pensando exclusivamente em lidar com quase máquinas ou recursos como é mais chamado atualmente com lembranças a revolução industrial. Se você se considera um recurso “datashow, ventilador, sala” eu recomendo fortemente procurar um psicólogo por que o stress passou dos limites. Quando estamos lidando com pessoas em um processo altamente criativo como software precisamos agir de forma diferente de uma obra de engenharia civil. Com o software o resultado final nunca será igual ao projeto inicial.  A visão do cliente vai mudar sim ao longo do projeto e compete a nós a agilidade de conversar com ele frequentemente e ir acompanhando a percepção do valor de negócio.

É incrível como percorrendo projetos de software em todo o Brasil nos últimos anos encontro sempre o mesmo cenário de pessoas insatisfeitas, usuários insatisfeitos e patrocinadores também insatisfeitos. Até hoje escuto de clientes que aguardam meses (processo em cascata) para saber que uma das funcionalidades mais importantes do sistema não vai ser implantada ou pior que recebem um monte de funcionalidade (cerca de 40% conforme estudos) que sequer estavam dentro dos objetivos iniciais e aparecem por que alguém achou que era importante e resultou em gordura inútil. Isso mesmo puro colesterol ruim que virou prejuízo de fato no bolso de quem pagou.

Nós poderíamos passar o dia todo conversando sobre todo esse ecossistema de desenvolvimento de software e seus problemas que certamente você já passou por uma dessas situações que acabei de comentar. É um fato real baseado em uma coleta de dados em diversos projetos diferentes baseados em desenvolvimento em cascata. Por ultimo, mas tão importante quanto é o fantasma mor chamado de documentação. Tai ai uma coisa fantástica que parece praga. Todos acreditam fielmente que tem que fazer isso para salvar o projeto. Mas nenhum sequer usa ou atualiza durante qualquer evolução do projeto.

Durante dois anos pesquisei internamente em todos os nossos clientes, durante palestras em várias cidades do Brasil com profissionais ligados a área de desenvolvimento e minha percepção é a mesma. Desenvolvimento tradicional em cascata é um grande factoide que não resolve os problemas dos projetos. Parece invenção criada pelos indianos para vender fábrica de software. Na prática é a fonte do telefone sem fio onde cada um coloca uma pitada e no final vira um buraco negro, pois não é usado na manutenção e raríssimos são as pessoas que atualizam. Para e pergunta isso ai na sua empresa.

A primeira coisa então para avançar no Scrum é justamente rasgar esses planos e paradigmas em cascata e passar a estabelecer uma relação de confiança e não de contratos com as pessoas que estão juntas trabalhando com você. É uma mudança cultural muito grande que tem que envolver toda a organização. Logo no primeiro contato no dia a dia de um projeto Scrum você vai perceber o impacto na colaboração e socialização com a formação de um time que seguira os passos de evolução Sprint a Sprint.

O Scrum traz de imediato três pilares importantes que é transparência, inspeção e adaptação que provoca um verdadeiro choque de ordem arrumando o projeto e literalmente tirando toda e qualquer poeira do lugar. Não existe como se esconder atrás de um cronograma por que as atividades no Scrum já são por padrão definidas dentro de  “Timebox” definido e não sobre alterações. Os ciclos de implementação conhecidos como Sprints podem variar de 2-4 semanas e é onde tudo acontece. Ao final do Sprint sempre terá uma entrega de valor.

A principal mudança imediata é que o cliente (Product Owner) passa a ter uma presença mais efetiva no projeto uma vez que somente ele define as prioridades. Com isso você consegue criar pequenas entregas  “Sprints” e ir buscando rapidamente o seu ROI (Return On Investment). Ou seja a cada entrega rápida de funcionalidade você já vai se aproximando do ROI diferente de um projeto tradicional onde teoricamente isso só vai acontecer ao final.

O papel do gerente ou melhor profissional de projetos é distribuído em três papeis no scrum que são eles: Product Owner (PO); Scrum Master (SM) e Time. Com isso você consegue separar bem a responsabilidade de cada grupo resumindo a visão do backlog e priorização com o PO, a manutenção do Scrum na organização com o SM e a transformação do valor de negocio em software funcionando com o Time que é multidisciplinar e auto gerenciável.

Quando o termo auto gerenciável aparece chega a chocar muita gente até hoje. Isso ainda faz parte de um momento conhecido como o comando controle que está em queda livre em qualquer organização seja de software ou não.

Estamos já hoje vivendo o momento da colaboração onde todos contribuem com suas habilidades na gestão do processo. E com o Scrum isso funciona muito bem de uma maneira muito simples. Se você não está comprometido com o seu time essa sua falha vai aparecer no outro dia na reunião diária do projeto. É impressionante que você não fala com o gerente que não entende nada e sim com seus colegas que estão no mesmo barco. O impacto dessa reunião é um fenômeno.

Com o Scrum os requisitos são esclarecidos diretamente com o cliente sem burocracia podendo mudar a cada entrega de Sprint. E isso é muito importante não adianta assinar um contrato e não entregar o que o cliente está buscando por que você vai entrar nesse caos que já conhecemos e se repete na maioria dos projetos atuais. O cliente não sabe o que quer e nem tão pouco nos sabemos entender o que ele está buscando. Com entregas rápidas você consegue ir alinhando essa percepção de valor e conquistando o cliente como parceiro.

De volta ao mundo de Alice. Aquela mesma do filme pare e pensa se você nunca viu uma situação parecida com essa. Alguém chega a sua mesa com um conjunto de atividades já estimadas e com data para entrega. Você olha as mesmas e sabendo que não vai entregar pega as atividades e inicia seu trabalho. Ambos sabem claramente que não vai ter entrega, mas ficam felizes com isso repetindo em loop esse ciclo.

No Scrum quem estima as atividades é quem vai implementar pois é a pessoa mais habilitada conforme suas experiências a determinar a complexidade de implementação. Para isso temos várias técnicas e eu prefiro o Planning Poker por no meu ponto de vista estimular a colaboração e garantir a voz de todos no momento das estimativas que é crucial em qualquer projeto de desenvolvimento de software. Quando a pessoa estima o efeito psicológico é enorme, pois nesse momento ela está se comprometendo. Estabelecer uma relação de confiança entre as pessoas e oferecer um espaço para escutar todos abre um caminho sem precedentes no projeto para a conquista da felicidade que não tem dinheiro que pague.

Ao final de cada reunião o time atualiza o Burndown que é o seu baselime de entrega do Sprint. Com ele conseguimos ter uma visibilidade plena de evolução e se estamos direcionados a entrega. Com o ciclo é curto se aparecer falhas é muito mais fácil corrigir no início do que no final. Outro fator importante é acabar com a síndrome do estudante ou dos 90% prontos. No Scrum está entregue ou não entregue e isso é medido ao final de cada Sprint. Na sequencia fazemos uma avaliação com uma retrospectiva geral para corrigir eventuais problemas e melhorar o processo.

Ao contrário do que todos imaginam a gestão com Scrum é muito mais forte. O gerenciamento de risco é feito todos os dias e a tomada de decisões é imediata. O time por ser auto gerenciável tem autonomia para resolver todos os problemas que aparecem e podem convocar sempre que necessário o cliente para problemas de negócios. O grande segredo desse Framework foi justamente compartilhar o gerenciamento e conseguir com isso multiplicar transformando todos em interessados no resultado. Isso faz uma grande diferença e é uma mudança de abordagem que você tem que promover. O resultado não é de uma pessoa especifica e sim do time.

[],
Ramon Durães
Especialista em desenvolvimento de software
MVP, Visual Studio ALM
PSM, Professional Scrum Master
PSD, Professional Scrum Developer

Está na hora de mudar em