As tão comentadas metodologias ágeis podem requerer adaptações dependendo do contexto e do tipo de serviço. Como seria para a engenharia?

O uso de metodologias ágeis se tornou a “bola da vez”. Scrum, DevOps, Extreme Programming e outros métodos ganharam seções cativas nas livrarias com milhares de livros lançados e vêm sendo tema de inúmeros cursos e palestras. Esse cenário levou várias empresas a quererem utilizar essas metodologias em seus processos, mas a aplicação dos conceitos pode não ser tão simples, requerendo adaptações conforme o contexto e o tipo de serviço.

Pela IHM Stefanini, atuei como Scrum Master em uma equipe de Scrum formada por engenheiros, em um projeto de adequação de uma planta industrial à NR-12 (norma de segurança de máquinas), por um ano. Ainda que tenhamos obtido sucesso no uso da metodologia, passamos também problemas e desafios que proporcionaram bastante aprendizado, nos fazendo repensar a forma de aplicar o Scrum e os fatores a serem considerados. Busco nesse artigo dividir um pouco desse conhecimento, relatando desafios práticos de se aplicar metodologia ágil a um ambiente nem sempre propício. Nessa primeira parte falaremos dos problemas, e numa segunda, de ferramentas que podem ajudar em sua solução, sempre levando em conta que não existe receita única e que cada projeto tem suas próprias dificuldades.

O tamanho das equipes

Inicialmente, a equipe foi formada de modo tradicional,considerando fatores como o tamanho do projeto, a produtividade de cada um e o prazo, e chegamos ao número de 16 pessoas. As tarefas eram divididas de forma que as mesmas pessoas ficassem responsáveis por um tipo de serviço em todos os setores da obra. Isso tornava praticamente impossível dividir o time em dois ou executar a mesma tarefa em dois setores ao mesmo tempo.

Fomos percebendo, no entanto, que isso não estava funcionando muito bem. O grande número de pessoas fazia com que as reuniões fossem longas e por vezes cansativas, além de levar as pessoas a ficarem dispersas. Muita coisa deixava de ser dita por causa do medo da exposição e o processo acabava ficando menos ágil do que poderia ser.

Fazendo balanço em nossas retrospectivas, chegamos à conclusão que a divisão em equipes diferentes seria necessária. Foi preciso modificar a forma como dividíamos as tarefas, para então montar dois times de oito pessoas, dentro do recomendado pelo Scrum. A diferença de desempenho foi notada não apenas nos eventos do Scrum e nas reuniões de trabalho, como também no desempenho das pessoas em si. A partir dessa mudança tudo passou a fluir melhor.

O Scrum defende que a equipe seja o mais transparente possível, com todos os membros compartilhando o máximo de informações e opiniões. Isso acontece com mais naturalidade quando a equipe se conhece melhore os membros desenvolvem uma relação de confiança entre si. Além disso, equipes pequenas fazem reuniões mais dinâmicas e se comunicam de maneira mais assertiva,o que permite alcançar resultados mais rapidamente  e contribui para um melhor clima entre o time. O tamanho das equipes, como ficou claro pra nós, não pode ser facilmente aumentado.

Falta de fé na metodologia ágil

O Scrum é uma metodologia e não uma técnica. Sendo assim, a execução de um projeto de engenharia tende a ser basicamente a mesma do ponto de vista técnico: o que muda não é tanto o que é feito, mas como as atividades são priorizadas e como são feitas as entregas. No entanto, mesmo que não exista nenhuma diferença do ponto de vista técnico, o Scrum requer uma mudança de paradigma.

O ser humano já é resistente a mudanças por natureza. No ambiente de engenharia, essa resistência é ainda maior, já que os profissionais estão acostumados a executar as atividades de uma determinada forma há muitos anos. E é preciso estar atento a isso, dado que muitas vezes a relutância não é questão de desconhecimento ou falta de treinamento, mas apenas vontade do profissional de manter o status quo.

A questão é que o Scrum requer um senso de trabalho em equipe muito forte e isso só é possível quando os integrantes têm a sensação de estarem todos no mesmo barco.  Como um profissional resistente não se identifica com os valores do Scrum, ele acaba não aplicando o método da maneira correta, o que pode prejudicar bastante a equipe. Os demais membros do time acabam se espelhando em quem não quer mudar a forma de trabalhar e passam a não se importar com a utilização do Scrum.

Quando começamos o projeto, pudemos constatar que havia alguns colaboradores realmente resistentes à metodologia. Quando, por um motivo qualquer, os resultados não saíam como o esperado, essas pessoas culpavam o Scrum e expunham sua descrença nele, por vezes contaminando todo o grupo, já que havia muitos que, embora não propriamente resistentes, ainda estavam em processo de adaptação. Ficou evidente que, embora o sucesso dependesse de um grande comprometimento de todos, um pequeno esforço negativo de alguém descrente poderia fazer tudo cair por terra.

À medida que o projeto caminhou, a quantidade de trabalho diminuiu e foi necessário desalocar profissionais do projeto. Eles foram realocados em outros projetos (que não necessariamente utilizavam metodologia ágil) e, com isso, o número de pessoas pouco engajadas com o Scrum diminuiu. A comunicação dos times começou a fluir melhor e, ao passo que os resultados ficavam mais evidentes, mesmo os membros que não estavam totalmente convencidos se empolgaram e passaram a ter fé na metodologia, o que facilitou em muito o processo.

Número de Product Owners por equipe

O Scrum é uma metodologia que trabalha muito com a noção de produto: mesmo um software é enxergado como produto em função de suas funcionalidades e trabalha-se para aprimorá-lo nesse sentido. O Product Owner,também chamado de P.O., é o colaborador cuja função é ter a visão do produto e organizar as tarefas a serem executadas pela equipe buscando produzir todas as funcionalidades necessárias.

Como na organização tradicional da empresa existem líderes técnicos para cada disciplina, a equipe foi montada com dois Product Owners. A ideia era dividir as tarefas de modo que um deles ficasse por conta da parte de elétrica e outro por conta da parte de automação. Constatamos na prática que isso não funciona. O Scrum trabalha com times multidisciplinares, e o P.O. deve possuir uma visão global do produto no âmbito de todas as disciplinas. Abrigar dois P.O.’s numa mesma equipe, ainda que para áreas distintas, pode levar o produto em direções diferentes, a conflitos e decisões desencontradas.

Estimativas sobre as atividades

Fazer estimativas é uma das atividades mais difíceis que existem. Além dos valores estimados frequentemente se mostrarem falhos e equivocados, normalmente eles tomam como base unidades de tempo (horas, dias,meses, etc.), que são valores absolutos. A falta de comparação relativa com algo realmente conhecido acaba gerando desproporções enormes, já que o tempo de execução de uma atividade pode variar muito dependendo da tarefa e da experiência do colaborador. Nesse cenário, uma solução interessante pode ser estimar as tarefas pelo esforço envolvido, medindo esse esforço em pontos.

No nosso caso, utilizamos o planning poker. Tomamos aquela tarefa que consideramos mais simples e bem conhecida e atribuímos a ela o valor de um ponto. A partir daí, toda nova tarefa passou a ser estimada de modo relativo, como múltiplos da tarefa de um ponto. Com isso a equipe aumentou drasticamente a capacidade de selecionar as tarefas para cada Sprint, melhorando o desempenho em aproximadamente 57%.

As indefinições nas tarefas e processos

Quando um projeto é desenvolvido do zero, as informações relacionadas à planta são mais abundantes e mais fáceis de serem acessadas. Portanto, o nível de indefinição das tarefas é relativamente pequeno. Já quando se lida com uma planta em funcionamento, como foi no nosso caso, com a adequação da planta industrial à norma NR-12, as coisas podem ser bem mais complicadas.