A transformação digital chegou. Várias empresas e governos sonham em diminuir a rigidez de processos administrativos, transformar e integrar sistemas de informação, prover serviços mobile, comunicação digital first e por aí vai. No entanto, ninguém sabe muito bem como chegar lá.
Se você é gerente de uma organização e o desafio da digitalização bateu à sua porta, você sabe muito bem a dor e a delícia de depender (as palavras desse texto foram escolhidas cuidadosamente) do sucesso dos projetos de uma equipe de tecnologia para chegar na tal plataforma de serviços digitais.
A oferta de soluções, em forma de ferramentas e métodos, é tão grande, que os problemas que precisamos resolver parecem estar se tornando acessórios. Tantas soluções voando em busca de um problema de verdade. Isso acaba nos deixando ainda mais com a impressão de “estar patinando”, de “estar dando voltas”, de “não sair do lugar”. Cada um traduz de uma forma o seu sentimento de vagar à deriva.
Ao mesmo tempo, os projetos de TI representam uma parcela cada vez maior dos orçamentos e continuam crescendo sem horizontes claros. A resposta padrão aos projetos em dificuldade é crescer a equipe.
Curiosamente, um estudo publicado pela IBM indica que os principais motivos para projetos falharem são “soft factors”, ou seja, fatores relacionados às pessoas (e suas idiossincrasias): modelos mentais e atitudes, cultura organizacional, subestimação da complexidade dos projetos e falta de apoio da alta administração.
Estive em algumas ocasiões no papel de gerente e, sem ter formação na área de tecnologia, sempre respeitei bastante a opinião dos técnicos das equipes com quem trabalhei. Tentei aprender com eles os desafios e dificuldades, para com isso manter a expectativa dos patrocinadores não muito longe da realidade.
Ao longo do tempo, fui aprendendo a manter um apoio crítico às equipes. Tive a sorte de coordenar o trabalho de alguns excelentes profissionais, mas sempre as equipes tinham enorme dificuldade de apresentar resultados correspondentes à qualificação de seus integrantes.
Nas ocasiões em que percebi que não tinha um repertório técnico suficiente para lidar com os meandros dos problemas que ameaçavam o sucesso (principalmente os prazos e entregas), decidi buscar o apoio externo de um consultor que tivesse, se não o domínio das tecnologias utilizadas, experiência para tratar os problemas técnicos na mesma linguagem da equipe, mas que, principalmente, conseguisse apoiar o grupo a ser mais produtivo de forma sistemática e não apenas por surtos de pressão.
Nesse ponto da história, entra o Brod. Não vou falar aqui do cara sensacional que ele é, pois somos amigos, mas não tem como separar o profissional da pessoa, do lado humano, dos seus valores e da sua busca por estar sempre inovando em projetos de colaboração aberta e voltados para um benefício público por meio da tecnologia.
As reações iniciais das equipes à chegada de um consultor de metodologias ágeis sempre foi muito curiosa: “nós já usamos Scrum”, “não precisamos de metodologia, mas de mais técnicos”, “não sei o que esse rapaz vai agregar, pois já usamos metodologia ágil”, entre outras pérolas do PZC (Partido da Zona de Conforto).
Conhecendo o Brod, sempre soube que bastava abrir a porta para sua chegada para que ele rapidamente ganhasse a equipe e provocasse uma revolução na produtividade.
Numa ocasião, em que não só a entrega estava comprometida, mas a minha confiança na equipe estava abalada, solicitei seu apoio não como consultor, mas como auditor. Exigi que ele não fosse simpático, que jogasse duro, que não saísse para almoçar ou para tomar cerveja. Bem, acho até que ele me enrolou bem nesse papel de auditor, pois em menos de um mês a equipe já estava entrosadíssima com ele. O importante é que a entrega foi realizada dentro do prazo e a confiança restabelecida.
Confesso minha total impaciência para os novos termos de qualquer nova metodologia. Com Scrum não é diferente: “Product Owner”, “Scrum Master”, “Histórias”, “Sprint Backlog” e por aí vai. Acho que tudo isso poderia ser traduzido em termos da linguagem comum, mas deixo que os feiticeiros façam sua magia livremente. O importante é que seja eficaz!
Se você decidiu embarcar na viagem ágil, seja no desenvolvimento de software, seja em projetos de qualquer natureza, precisa estar ciente que não é um método que você vai comprar na prateleira das consultorias.
Este Scrum – Guia prático para projetos ágeis (e Pessoas Felizes) não é mais um manual da metodologia que você encontra nas livrarias. Para ser ágil, tem que ser inquieto. Para ser ágil, tem que ser criativo, mas tem que gostar de rotina também. Para ser ágil, tem que andar de mãos dadas com a equipe e buscar o equilíbrio.
Se alguém trouxe esse livro até você ou se você mesmo o encontrou, leia-o. O autor vai estar ao seu lado discutindo e ajudando a implantar as ideias que estão nele. Você vai sentir ele lá. Esse livro carrega mais do que conhecimento, nele você encontrará muito do idealismo, solidariedade, ética e da motivação do Cesar Brod. Coisas tão necessárias para se chegar ao resultado que todos esperamos.
