Para muitos é “ame-as ou deixe-as”. Para outros, elas são cultuadas e precisam ser seguidas à risca, quase como uma religião. Mas as práticas ágeis estão apoiadas em conceitos simples, com foco na interação das pessoas para solução de problemas e entregas de valor. Desta forma, sua adoção permite que você avalie quais melhores práticas se encaixam na sua necessidade e como as mesmas devem ser implantadas.
Particularmente, não acredito que exista uma “receita de bolo” para se utilizar em todas as situações. Existe um arsenal de práticas e metodologias que podem e devem ser utilizadas de acordo com o cenário encontrado em cada organização. Não se trata de implantar as metodologias ágeis para seguir a tendência atual, ou para solucionar todas as deficiências nas entregas de produtos ou projetos, mais especificamente os de Tecnologia. Trata-se de identificar e entender o problema que se quer resolver: falta de alinhamento estratégico, falta de comunicação com os clientes, falta de gestão do portfólio de projetos, inexistência de processo para criação de produtos, baixa qualidade da entrega, falta de processo de desenvolvimento de software, desmotivação da equipe e etc. Muitas vezes, uma combinação de vários deles ou de todos eles até. E os caminhos são diversos.
É sempre bom também contar com o patrocínio da alta gestão da empresa para uma mudança, mas, eventualmente, isso não acontece de início. Com relação às práticas ágeis, vender esta ideia para o board, nem sempre é fácil. Apesar dos conceitos simples, eles podem soar tão simples que não ganham credibilidade. E isso é normal. Então, como fazer? Bem, é preciso mostrar que funcionam! Nestes casos, vale montar um piloto e começar devagar, “comendo o mingau pelas beiradas”.
Temos alguns casos de sucesso para mostrar que a abordagem para adesão às metodologias ágeis depende de cada contexto, e que não adianta implantar indiscriminadamente, “goela abaixo”, as mais modernas práticas disponíveis de uma vez. Um caso que evidencia bem esta situação aconteceu em uma grande empresa de mídia. As práticas ágeis chegaram como uma boa novidade. Houve certo entusiasmo da alta gestão para seu uso, cuja promessa era garantir mais entregas de produtos em espaços de tempo cada vez mais curtos. Tudo o que eles queriam. No entanto, não houve patrocínio para uma mudança de cultura e processos que precisava permear todas as áreas, em não apenas a TI, no desenvolvimento de produtos. Mas foi a Tecnologia que efetivamente comprou a ideia e sua implantação, através da média gerência.
Os times foram envolvidos e se comprometeram com a mudança. As primeiras experiências não deram nem tão certo, mas o aprendizado adquirido e compartilhado mostrava claramente que o caminho era aquele. Interessante constatar o quanto as equipes de desenvolvimento identificaram-se com o novo processo e motivaram-se com ele. E esse foi apenas o início. Fundamental, porém, para embasar todas as demais mudanças que estavam por vir.
O cenário era complexo. A empresa, motivada pelas dificuldades e os desafios da indústria de mídia, passava por grandes mudanças: organizacional e estratégica, que fez com que a mesma investisse na troca de sua plataforma de publicação. A equipe de Tecnologia estava crescendo rapidamente e absorvendo novos profissionais, muitos deles mais juniores. Absorvia também novas ferramentas e não existia um processo maduro de desenvolvimento. Longe disso! A área de TI também sofria com os prazos apertados e as entregas não cumpridas. Portanto, apesar da necessidade de modernização urgente, não dava para se fazer tudo ao mesmo tempo. O risco de comprometer ainda mais as entregas e acabar de vez com a credibilidade da Tecnologia era enorme.
O início se deu com a adoção de metodologias ágeis para gerir as atividades da equipe de desenvolvimento: num primeiro momento o Scrum, com algumas pitadas do Kanban. Os resultados junto aos times foram animadores e vieram rapidamente: as entregas começaram a fluir e, cada vez mais, os clientes estavam mais próximos desta rotina, respirando os produtos. Em pouco tempo, o time de desenvolvimento virou a equipe do produto. Ótimo! Era este o ambiente desejado.
Hora de fazer mais mexidas, agora no processo de desenvolvimento: novos conceitos foram incorporados como a orientação a testes e o foco em qualidade. Mais adiante, foi criada a “cesta de indicadores de qualidade”, com o objetivo de medir o desempenho, aumentar a transparência junto ao usuário e tangibilizar melhor o aprendizado da equipe. Toda esta evolução feita paulatinamente e com a participação efetiva das equipes, exatamente para criar o estado de pertencimento e propriedade.
Desta forma o comprometimento, não apenas com o produto a ser entregue, mas com os processo e práticas garantiu que as mudanças ocorridas passassem a fazer parte da nova cultura corrente.
Mas tudo a seu tempo. Respeitando-se as limitações da empresa, da gestão e das equipes e levando-se em consideração o contexto e o momento corporativo. Não é problema se permitir fazer concessões às práticas ou métodos ou abordagens, desde que se respeite os conceitos fundamentais e o foco na conscientização de uma nova filosofia de trabalho participativa, transparente e colaborativa.
