Existe um ditado chinês globalizado que diz: “Se deres um peixe a um homem faminto, vais alimentá-lo por um dia. Se o ensinares a pescar, vais alimentá-lo por toda a vida”.

Com essa máxima, trago a reflexão que faço há alguns anos: até que ponto as pessoas estão preparadas por default para trabalhar nesse novo cenário pós-Fordismo, com várias metodologias e processos contemporâneos que ditam que as pessoas devem ser/estar motivadas, proativas e auto-organizáveis para fazerem o unlock do verdadeiro sucesso?

Algumas empresas buscam sua tábua da salvação em frameworks consagrados, como o Scrum, metodologias ágeis, como o XP e um monte de livros de receita com roteiros de atividades para um time de desenvolvimento e gestão de produtos ter sucesso. São formulas que andam ombro a ombro com o jeito lean e agile de tocar a vida, os projetos e tudo mais da economia atual.

Isso garante (ou não) o peixe. Mas ensina as pessoas a pescar?

O Manifesto Ágil, quase como uma tábua de mandamentos do mundo ágil, define: “Indivíduos e interação entre eles são mais que processos e ferramentas”. Em seus princípios, um em especial fala “Construir projetos ao redor de indivíduos motivados, dando a eles o ambiente e o suporte necessário, confiando que farão seu trabalho”. Outro diz “Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto”.

Motivação, confiança, trabalhar em conjunto, ambiente e suporte… Pode uma empresa conseguir o sucesso pretendido simplesmente implantando uma metodologia ou framework ágil no seu time de trabalho? Isso sem mudar seu próprio mindset e a cultura interna para prover às pessoas um ambiente e suporte que tragam motivação e confiança entre elas?

Pessoas > processos

7 anos atrás me encontrava numa recém-aberta startup com meus sócios. Debaixo dos braços, um monte de livros de Scrum, XP, Lean e exemplos de empresas que admirávamos e que estavam indo super bem e já eram ágeis. O que faríamos para fazer as coisas acontecerem? Um dos motivos de termos começado uma empresa é que tínhamos certeza de que os resultados não eram apenas gerados por processos, mas especialmente pelas pessoas. Queríamos fazer diferente.

Então, do alto da nossa “sensatez empreendedora”, gastamos metade de nosso capital social inicial em três itens que eram de vital importância para que as pessoas (a gente, no caso) ficassem bem: uma cafeteira legal, um ar condicionado potente e uma televisão para ligarmos o videogame. Naquele momento fizemos uma autoafirmação importante e genuína: queremos que as pessoas sejam felizes e fiquem bem. Google, Facebook, Spotify e tantos outros exemplos traduzem de forma clara e reconhecida que o mindset real de prover um ambiente e suporte para fazer as pessoas felizes e se manterem motivadas. A motivação por si só não gera felicidade e vice-versa, mas, por outro lado, uma não vive sem a outra.

Descobrimos que pessoas felizes fazem software de qualidade que deixa clientes felizes. Mas não era apenas um frigobar com cerveja, flexibilização de horários, dress code zero e tantas outras coisas que se materializaram depois de um ano de atenção da mídia e do mercado local (chamavam-nos carinhosamente de Google Capixaba), contratos bacanas sendo feitos (o maior deles com a Wine.com.br) e clientes felizes com os resultados do trabalho.

É essencial as pessoas trabalharem bem em conjunto. Como lidar com uma pluralidade de experiências, expertises, personalidades num ambiente que deveria ser leve e ao mesmo tempo produtivo o bastante para a realidade de uma startup?

Esse build de confiança por vezes é deixado em segundo plano em detrimento de um monte de consequências que as metodologias ágeis deveriam fazer brotar no coração de todos. Deveriam? Como fazer uma Sprint Retrospective ser realmente efetiva se as pessoas têm um monte de problemas não-técnicos na sprint? Como a reunião diária em pé pode servir ao objetivo de dar feedback sobre os problemas do time se as pessoas ainda têm medo de se expor?

Realizamos esse build apoiados no ciclo:

• Aprendizado, para potencializar o que a pessoa tem de bom e o que ela precisa para difundir isso dentro da empresa. É importante ter sensibilidade e tato pra entender que o técnico tem que andar de mãos dadas com o comportamental, e vice-versa. Uma pessoa extremamente técnica que não tem os skills pra repassar esse conhecimento para frente, um gênio que não sabe trabalhar em grupo, nem aceita críticas, o líder que não é servidor. No outro extremo, a pessoa de boa lábia que não programa direito, o servidor que não lidera, nem assume seu papel…
• Admiração/Exemplo, que nasce naturalmente quando se observa a pessoa dando o melhor de si pra melhorar e aprender. A admiração e o exemplo fazem as pessoas se espelharem, se motivarem e, num caso extremo, saírem do seu eixo normal. Ora, o que estou fazendo para acompanhar essa pessoa e não me tornar irrelevante?
• Respeito (mútuo), então, se faz existente quando o aprendizado se consolida e a admiração é relevante o bastante para enxergar no outro o reconhecimento de alguém que venceu as barreiras e as dificuldades para melhorar.

Times > pessoas

Como você se sente trabalhando com alguém que você admira e respeita?

O conceito de time das metodologias ágeis sempre mostra os times como grupos auto-organizáveis, autônomos e que devem entregar um resultado após uma iteração. Resguarda-se que eles devam também ter coragem. Mas como ter coragem se você não confia nas pessoas? O build de confiança que tinha sido feito, manifestava nos times alguns comportamentos que, independentemente das cerimônias Scrum e práticas XP, acabaram fazendo parte de praticamente todos os times.

Com sua autonomia e nossa filosofia de hierarquia horizontal, os times acabavam fazendo emergir os líderes naturalmente. Em todo projeto, às vezes por mais de uma vez, os times tornavam visíveis quem era o líder que conduziria aquela sprint ou até o projeto. Não eram líderes por cargo ou por uma escolha top-down, e muito menos tratados publicamente assim – eles apenas eram.

Olhando especificamente, essa estrutura social de tribo fazia até mesmo os times terem seu próprio comportamento específico, regras e condicionais. Independentemente de utilizarmos as mesmas metodologias, o comportamento específico do grupo era singular. Eles se desafiavam a errar rápido para aprender rápido. Os recém-contratados eram incentivados a codarem no primeiro dia e enviarem código para a base de produção. Isso era comemorado pela empresa inteira. Esse “acontecimento” gerava uma vibe de pertencimento e realização indescritível na pessoa e no time. Errou? O time estava lá pra te ajudar a corrigir e te ensinar onde aconteceu o erro. Geralmente, tínhamos novatos já participando de grandes deploys em produção com poucas semanas.

Os times se tornaram generalistas prestativos. Todos faziam de tudo, mas alguns eram especialistas em algo que guiava todos. Lembram dos líderes naturais? Aqui eles eram ainda mais específicos, causais e contextuais.

Esses comportamentos se explicam um pouco com a Teoria da Aprendizagem Social, de Alberte Bandura, que diz “As pessoas podem aprender a partir da observação de outras pessoas que praticam um determinado comportamento”. Isso é reforçado por uma necessidade de aceitação de grupo e social, que é instintiva e mais forte que qualquer regra imposta. “Se todo mundo ajuda um ao outro, eu vou ajudar também”.

Cultura > Times

Num dado momento, descobrimos que nosso build de confiança estava sendo feito pelos próprios times. Mas o que é interessante é que mesmo as pessoas mudando de time e mudando de tribo, elas continuavam no seu ciclo do build de confiança e mudando o mindset dos times em que entravam.

Algumas cerimônias, que eram feitas de um jeito, eram polinizadas pelas ideias e conceitos que umas pessoas de um time X levavam para o time Y em que elas foram inseridas. Esse comportamento não era ditado, forçado nem requerido. Os times, apesar de singulares no que diz respeito a comportamento, regras e leis sociais e às pessoas, e de se comportarem de acordo com o que o seu time ditava, conseguiam se adaptar e trabalhar bem em outros times, que às vezes eram completamente diferentes.

Isso foi posto à prova quando novos times, com gente totalmente nova, se formaram. O contato com outras pessoas que tinham pertencido a outros times fazia aquele time se moldar à forma como todos os outros times trabalhavam. Nossas pequenas ações, momentos e práticas formaram, então, nossa cultura, que estava moldando os times para constituírem a confiança das pessoas. Uma cultura forte ajuda as pessoas a serem felizes e darem o seu melhor. Pessoas em qualquer negócio, em qualquer lugar.

Toda essa história vem desde 2009 e, no início de 2016, todas essas pessoas e times viraram parte da Wine.com.br, o maior e-commerce de vinhos da América Latina e o terceiro do mundo. Saímos de uma casa para uma empresa com umas 400 pessoas, operação, logística, marketing, controladoria, financeiro… Toda uma forma de agir e resolver os problemas com algumas dezenas de desenvolvedores e nossa experiência em e-commerce e software debaixo do braço. Saímos da nossa codação de software do dia a dia para um cenário de gerar resultados para uma empresa que, mesmo online, é essencialmente varejista, e a geração de valor final era diferente da que a gente estava acostumado a fazer (software x vendas).

O que aconteceu foi que a cultura dos times foi junto. Mesmo com a mudança de lugar, ambiente corporativo e afins, sabíamos que nosso propósito ainda era criar o melhor software que podíamos para nosso cliente, que agora era exclusivo e único.

Então, isso funciona em qualquer lugar, em qualquer empresa. E não pense que isso é só para software. O que importante mesmo é ter um propósito, ter uma cultura forte, com times de pessoas felizes para eles darem o seu melhor.

Hey ho, let’s go.