Ágil em (um) banco: Do entusiasmo ao fracasso!

Para estreiar este blog, nada melhor do que começarmos contando um case que tive conhecimento e que nos faz muito aprender.

Aprender com os erros é sempre uma grande oportunidade de crescimento e melhor ainda se for com os erros dos outros, então aproveite a leitura e saiba extrair as lições que teremos aqui.

O caso

A adoção de metodologias ágeis por uma equipe de desenvolvimento com espírito desruptivo dentro de um ambiente corporativo nativamente não ágil.

O cenário inicial

Um ambiente conturbado com equipes não integradas, clientes desinformados, falta de liderenças e recursos restritos.

Somado a isso, havia duas plataformas tecnológicas distintas, com ambientes segregados, gestores diferentes e ambas com necessidades de evoluções e aprimoramentos em suas arquiteturas.

A empresa vivia um momento de expansão e necessidades de TI, projetos surgiam pelos corredores nos mais diferentes moldes: pequenas demandas, projetos pontuais e também os famosos projetos medidos em escalas anuais! Os solicitantes? Todos… ou melhor… qualquer um!

A bala de prata

Alguns conceitos de gestão de projetos baseado em metodologias ágeis já eram praticados por parte desta equipe, como por exemplo os sprints e suas reuniões de planejamento baseado em estórias de usuários, mas nada muito além disso. A verdade é que o grande impulso para a mudança do cenário de desenvolvimento veio após alguns membros da equipe buscarem um aprofudamento no assunto “metodologias e ideologias que poderiam nos ajudar aqui”. E nessa busca chegaram a uma lista de ações que seriam tomadas e tinham a certeza que, uma vez implementadas, o sucesso seria certo! Certo!? Será!?

A lista era a seguinte:

  • Pair Programming
  • Gestão Visual
  • MVP (minimum viable product)
  • Coding Dojos
  • DevOps
  • Retrospectivas

O resultado

Pair programming fundamentalmente é muito interessante, quem nunca presenciou uma aglomeração na mesa de algum funcionário quando algum problema acontece e uma atitude rápida e eficaz precisa ser tomada. Duas pessoas trabalhando juntas teoricamente podem ser mais eficientes do que duas pessoas trabalhando separadas, mesmo que estejam dividindo a mesma estação de trabalho…. e é ai que o problema começa.

Sabemos que não são todos os profissionais que se adaptam a novas metodologias e práticas que surgem no mercado, um exemplo disso é o Pair Programming, onde a habilidade social também deverá ser considerada. Ora, dividir uma estação de trabalho durante horas… dias… semanas… é algo que força uma aproximação e um relacionamento social muito forte. Se as pessoas não se sentem confortáveis com isso, como atingir o objetivo de produtividade esperado? Lembrando que produtividade está ligada diretamente a motivação. E como estar motivado tendo que todos os dias dividir um espaço com alguém que socialmente não te agrada?

Além do mais, trabalhos paralelos intercalados com o trabalho pareado pode render mais ainda e para isso é necessário que cada um tenha a sua estação de trabalho.

Resultado do Pair Programming: Funcionou no início, talvez pela empolgação, mas a convivencia forçada não foi positiva, as pessoas não se sentiram bem.

A culpa foi delas?… Claro que não. A culpa foi do líder, por pressupor que as pessoas trabalhariam em pair tranquilamente somente com a utilização do argumento que seriam mais ágeis e eficientes. Um erro.

Isso foi o começo… veja continuação no próximo post!

Valeu!

 

 

 

 

 

 

 

Source: Ornito

Recent Posts

Leave a Comment