Práticas ágeis: Para cada tipo de paciente, uma dose do remédio

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.

(*) Cláudio Barizon é diretor de Negócios Digitais da TeamWare