Bom ambiente pode compensar a inexperiência de um time?

Uma vez eu trabalhava em uma empresa que estava na seguinte situação: nós tinhamos que criar uma equipe para um novo produto. Existem algumas técnicas que podemos empregar para formar equipes de alto desempenho, mas desta vez, apesar de poder admitir desenvolvedores com vários niveis de conhecimentos, o nosso orçamento mensal para o projeto era bem limitado. Nesta situação eu poderia contratar de quatro a cinco bons desenvolvedores júniors. Para a gente, parecia uma boa opção a médio prazo e cabia no nosso valor estipulado.

Como uma equipe nova no "estilo startup", tentamos empregar as melhores práticas sobre organização empresarial, gerenciamento 3.0 e processos ágeis. Sabemos que o trabalho de TI é um trabalho do conhecimento que tende a criar coisas a partir de Sistemas Complexos, e para que uma equipe possa render nesse tipo de trabalho, ela necessita de certas liberdades e facilidades.

Criamos então um ambiente mais sadio e liberto, com várias facilidades e pensando no bem estar das pessoas. Tiramos todo impedimento e burocracia que poderia atrapalhar o pensamento crítico e a criatividade, como por exemplo:

• Não colocamos ponto para obter liberdade de tempo.
• Compramos comida, suco, refrigerante, mate e cerveja, para ser consumido durante o experiente.
• Deixamos os móveis mais cool e cadeiras confortáveis.
• Empregamos Agile "by the book", sempre falando sobre sua cultura, além das técnicas, murais na parede e demais artefatos.
• Colocamos a ideia de diversidade e multidisciplinaridade.
• Os salários não estavam abaixo do mercado.
• Equipamos uma sala com bancadas que ajudavam na comunicação e o pareamento.
• Etc, etc.

Olhando isso bem ao longe, do outro lado do túnel, parecida que nossa equipe seria muito boa e produtiva. Com ela nossos projetos fariam sucesso conforme o esperado, já que preparamos uma boa estrutura para tal, e manteríamos essa mesma ideia de estrutura enquanto a empresa estivesse viva. Os sócios possuiam tal mentalidade e tendiam a ser o mais simples, objetivos e justos possíveis.

Com relação ao nível de conhecimento da equipe, e sabendo que eram inexperientes, ministramos internamente um treinamento para os desenvolvedores. Passamos por todas as tecnologias que compunham o projeto e colocamos bem próximo a eles um membro experiente para tirarem dúvidas. A equipe era pequena, o projeto novo e as tecnologias eram as mais atuais no mercado.

Bom, então deu tudo certo e o projeto foi um sucesso?

Quase.

Vamos voltar a atenção a um item bem específico: todos os nossos desenvolvedores eram estreantes na área de programação. Sem exceção, era o primeiro projeto da vida deles. Infelizmente no decorrer do andamento este item irá mostrar que a técnica sobrepuja todo o ambiente, por mais sadio e criativo que ele possa ser.

Na fase inicial deste projeto fizemos ao todo três Sprints, mas nenhuma delas fora cumprida. Bom, identificar problemas é um dos pontos que pregam os processos ágeis. Vamos agir então:

• Colhemos feedbacks nas restrospectivas e indicamos pontos de melhoria dentro da equipe.
• Pareamentos e pomodoros foram empregados.
• Usamos o Scrum mais a risca, além de gerenciarmos melhor as reuniões diárias, para que aconteçam de forma correta na ajuda ao time.
• Fomos seguros e estimamos menos pontos.
• Alinhamos o foco, para menos distrações, e ajustamos os horários da equipe.
• Realizamos um DOJO para melhorar o nível de conhecimento e prática.

Depois disso mais cinco Sprints foram realizadas, mas ainda sem cumprimento das atividades, e assim, reuniões e agendamentos de entregas aos clientes foram remarcadas. Como o ambiente era bem transparente, frustrações internas começam a acontecer, o que ocasionou em ainda menos foco, consequentemente, mais atrasos. Acabou virando uma bola de neve, e o ambiente cool, não aparentem mais tão cool assim.

Mas por que isso aconteceu? Por mais que a equipe fosse nova, tivemos treinamentos, temos apoio, empregamos as técnicas a lá XP, etc, etc. Fizemos o que estava ao nosso alcance.

Bom, o maior problema pode ser resumido em uma palavra: maturidade. A nossa equipe era imatura. Por mais que empregamos as técnicas e as boas práticas, erros vão acontecer, e não digo só em código ou do processo de desenvolvimento em si, mas erros de afinidade, foco, engajamento, pro-atividade, relacionamento e sinergia. A imaturidade pode levar a problemas fora de controle que tende a impactar no andamento do projeto como um todo. Este artigo acadêmico diz que "o grau de maturidade de equipes de trabalho é fundamental para viabilizar inovações tecnológicas e construir o conhecimento nas empresas. É a partir das experiências vividas que as inovações tecnológicas e a construção do conhecimento organizacional podem acontecer. Equipes com maior grau de maturidade tendem a constituir um ambiente mais favorável para criação do conhecimento e ser mais inovadoras".

Dificilmente algum outro processo de software irá ajustar este item dentro da equipe, ainda mais quando todos os nossos membros possuem este tipo de comportamento. Dessa forma, mesclar pessoas com diferentes níveis de conhecimentos faz o time se mover melhor e mais seguro e pode ser uma forma de resolver a imaturidade, mas quando se precisa de maior velocidade na entrega de valor, o resultado poderá não ser o esperado, não importando toda a boa estrutura que montamos e o ambiente em volta do time.

Um contraponto: caso tivéssemos um bom tempo inicial sem precisar de entregas, ter mais juniors poderia ser realmente uma alternativa. Com alinhamentos e apontando a direção certa, no passar do tempo, o amadurecimento aconteceria naturalmente e também a estabilidade.

Se pensarmos bem, a ideia que a técnica pode sobrepujar um ambiente complicado faz sentido dado que encontramos casos de empresas burocráticas e cheias de problemas, mas que os desenvolvedores experientes conseguem entregar o software. Com certeza ali possui pessoas maduras o bastante para anular o ambiente ruim. Em outra empresa tinhamos um grande projeto a ser entregue, onde as pessoas usariam o produto e a expectativa era grande, só que com curto prazo e numa equipe extremamente hierarquizada. Casos de usos demoravam para serem escritos e acabavam reescritos quando retornávamos, além de equipes distintas para testes e banco de dados, onde a própria equipe do projeto não poderia adentrar nessas técnicas. Somam-se a isso um processo cascata gerenciado.

Com uma equipe de quatro sêniors já experientes em Agile e neste tipo de ambiente, barreiras foram ultrapassadas, problemas foram rapidamente solucionados ou postergados e o sistema foi entregue no tempo e com boa qualidade. Internamente na equipe formamos um "mini agile" para que entre nós não houvesse impedimentos. Reuniões diárias mostravam para nós mesmos os problemas externos e apontávamos entre nós quem iria resolve-los, sendo verificado no outro dia se fora resolvido. Um mural formava nosso Kanban para medição do fluxo, lembrete de impedimentos ou Débitos Técnicos. A tecnologia era natural para todos e quando precisavamos, a qualquer momento, formava-se pares ou trios para resolvermos problemas pontuais. Com esse dinamismo quase que natural, mesmo com os problemas em volta, o sistema não só foi entregue como está no ar até hoje.

Então, além de todas as demais preocupações de nossa área ao montarmos uma equipe, temos que tomar bastante cuidado quanto ao nível tecnico sobre os desafios em que eles irão passar. Dependendo do que precisamos, isso pode ser a chave de sucesso do projeto.

Você já passou por problemas parecidos? Como você resolveu a questão da maturidade na sua equipe? Para saber mais sobre gerenciamento de times ágeis, participe dos nossos cursos de Scrum.