Eu tenho acompanhado o desenvolvimento de 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. Vi também todos os conflitos relacionados para gerenciar um processo criativo, complexo e altamente dinâmico como é um projeto de desenvolvimento de software.

Quando começo a conversar sobre a 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 têm o papel formal de gerente para cuidar do projeto e que não confiam nessas coisas meio descontroladas. 

É engraçado que essas histórias se repetem várias vezes. A minha primeira abordagem é pedir para ele avaliar como no momento está o caos gerenciado, e começo apontando problemas no modelo tradicional atual, como cronograma que não acaba nunca, falta de qualidade e todo retrabalho que fica oculto no cronograma do gerente. A verdade é que você não encontra um gerente que aponte no centro de custo o prejuízo de um projeto.

A visão de fábrica de software em cascata não funciona nem nos livros. Acabou-se o tempo em que se faziam os projetos pensando exclusivamente em lidar com quase máquinas (ou recursos), como as pessoas são chamadas atualmente com lembranças a Revolução Industrial. Se você se considera um recurso (datashow, ventilador, sala), eu recomendo fortemente procurar um psicólogo, porque o estresse passou dos limites. 

Quando estamos lidando com pessoas em um processo altamente criativo como software, precisamos agir de forma diferente ao de uma obra de engenharia civil, na qual o resultado final (a edificação) tem que estar exatamente como no projeto inicialmente elaborado, senão a estrutura cede e o edifício cai. 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 usuários e patrocinadores 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 funcionalidades (cerca de 40%, conforme estudos) que sequer estavam dentro dos objetivos iniciais e aparecem porque alguém achou que era importante, resultando 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 esse enorme ecossistema de desenvolvimento de software e seus problemas, pois 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 último, mas tão importante quanto, é o fantasma mor, chamado de documentação. Está aí uma coisa “fantástica” que parece praga. Todos acreditam fielmente que é necessário fazer isso para salvar o projeto. Mas ninguém sequer usa, ou atualiza durante qualquer evolução do mesmo.

Durante dois anos pesquisei internamente em todos os nossos clientes, durante palestras em várias cidades do Brasil com profissionais ligados à área de desenvolvimento e minha percepção é a mesma. Desenvolvimento tradicional em cascata é um grande factóide 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 em que cada um coloca uma pitada e no final vira um buraco negro, pois não é usado na manutenção, e raríssimas são as pessoas que atualizam. Pare e pergunte isso em sua empresa.

Então, a primeira coisa 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 na socialização com a formação de um time que seguirá os passos de evolução Sprint a Sprint.

O Scrum traz de imediato três pilares importantes, que são transparência, inspeção e adaptação, que provocam 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, porque 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 a 4 semanas e é onde tudo acontece. Ao final do Sprint, sempre haverá 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, no qual, teoricamente, isso só vai acontecer ao final.

O papel do gerente, ou melhor, profissional de projetos, é distribuído em três papéis no Scrum. 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 negócio em software funcionando com o Time, que é multidisciplinar e autogerenciável.

Quando o termo autogerenciável aparece choca 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 hoje vivendo o momento da colaboração, no qual 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 fale 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.

No Scrum os requisitos são esclarecidos diretamente com o cliente sem burocracia podendo mudar a cada entrega de Sprint. E isso é muito importante, pois não adianta assinar um contrato e não entregar o que o cliente está buscando, porque 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 nós 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 pense se você nunca viu uma situação parecida com essa. Alguém chega à sua mesa com um conjunto de atividades já estimadas e com data para entrega. Você as olha e, sabendo que não vai entregar, pega as atividades e inicia o 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 à entrega. Como o ciclo é curto, se aparecerem 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, e isso é medido ao final de cada Sprint. Na sequência, 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 pode 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 específica, e sim do time.