Bruno Eugênio

Uma das coisas que mais ouvi falar desde quando iniciei minha carreira em desenvolvimento de software foi acerca de frameworks ágeis e em especial o Scrum. Inclusive, trabalhar com times que rodavam scrum foi um dos motivos de abandonar um emprego com 3 meses de contratado (desculpas, Clayton!) para voltar a ser estagiário em uma fábrica de software.

Posso dizer que, depois de quase cinco anos vivendo o dia a dia de times que tentam aplicar Scrum como modus operandi do time, o scrum é apenas um propulsor e é DESCARTÁVEL quando o time atinge o voo de cruzeiro. Claro que seria negligência minha negar os principais poderes do Scrum em um time: fazer com que os membros entendam que comunicação clara, conhecer o quanto se pode entregar e ser transparente com o que vai entregar, são premissas básicas no atribulado mundo do desenvolvimento de Sotware. Nisso, o Scrum foi disruptível em relação aos métodos tradicionais de gerenciamento aplicados até então, mas não significa que é algo que o mesmo precise ser repetido a exaustão em um time que entende seus princípios básicos.

O Scrum é, antes de tudo, um método ou mecanismo de trabalho de um time multidisciplinar e heterogêneo. Lá vão constar os métodos para lidar com situações de todos os tipos como decisão, controle e medição. Além de provocar o envolvimento de partes que, em meios normais, ficariam longe do processo como o cliente na figura famosa do Product Owner, o Scrum ajuda os times a encontrarem a famosa “velocidade de cruzeiro” que é saber, de fato, quanto do trabalho você vai conseguir entregar em um determinado período de tempo (timebox).

Com isso, as pessoas pouco param para pensar que todo o ritual do Scrum se torna, em voo de cruzeiro, uma coisa totalmente sem sentido!

Sejamos sinceros: Quando um time passa a rodar em voo de cruzeiro, com todos se conhecendo bem, um quadro relativamente atualizado (em especial os eletrônicos, ligados diretamente as atividades) qual é o membro do time que não sabe o que raios o outro está fazendo? E que não saiba o critério de aceitação de um product owner? Só sendo MUITO inocente para querer manter todas as cerimônias useless?

Imagine o Scrum como o propulsor de um foguete inter espacial: Quando o foguete alcança uma altura onde a nave principal pode se mover sozinha, os propulsores são descartados! O que fica no foguete principal é o seu time e toda a cultura que deve ser inerente a toda a empresa: Times unidos contra adversidades, código limpo, técnicas de refactoring e testes unitários, atenção ao cliente… tudo isso é resultado de um trabalho que não é “apenas” o Scrum e sim o mesmo com diversas outras técnicas (como as já citadas acima, UX, lean startup…) e pessoas ajudando a impulsionar, adaptar e condensar tais práticas dentro do seu projeto e em maior escala, na sua organização.

nova

USS Endeavour

Atlantissts04

USS Columbus

Avaliar como as práticas ágeis estão sendo vistas pelos novatos é uma ótima medida para avaliar se seu time está “escorado” no agile ou se ele entende o real valor das práticas que são utilizadas com base nos frameworks: Se ele, novato, está apenas fazendo por uma questão de processo do time é um mau sinal – ele está rodando no piloto automático, sem condições de adaptar – ou de entender no caso de uma adaptação – o framework com o qual ele trabalha. E fazer por fazer é a pior coisa que você pode ensinar a um membro de time.

Sendo assim, não se preocupe no seu próximo projeto em manter o Scrum como um ritual e sim se preocupe em explicar e espalhar a cultura de resultados baseado em agilidade e compromisso. O Scrum é apenas UM dos métodos – e com a quantidade de material disponível na Internet me arrisco a dizer que é o mais fácil de ser entendido e aplicado – para seu time alcançar o resultado. O café é importante, claro, mas não se esqueça de alimentar a cultura de projetos do seu ambiente dia a dia. Se não ela fica sem forças e termina engessada.

comentários

comments

Leave a Reply

Your email address will not be published. Required fields are marked *