Bate papo sobre o livro From chaos to Successful Distributed Agile Teams

Johanna Rothman e Mark Kilby escreveram o livro From Chaos to Successed Distributed Teams: Collaborate to Deliver, onde fornecem conselhos para os envolvidos em equipes distribuídas sobre como superar os desafios mais comuns, e os não tão comuns, que o trabalho remoto e a distância trazem para uma colaboração eficaz da equipe.

O livro pode ser adquirido aqui ou aqui e os leitores do InfoQ podem acessar um capítulo de amostra aqui.

Rothman e Kilby conversaram com o InfoQ sobre suas ideias.

InfoQ: Por que escreveram este livro? Qual é o problema que desejam solucionar?

Johanna Rothman: Durante o Agile 2017, eu caminhava para a última sessão quando encontrei Mark [Kilby] fazendo o mesmo. Perguntei-lhe: "Você viu algo útil sobre as equipes ágeis distribuídas?".

Ele disse, "Não, você viu?".

Eu disse, "Não". Pensei por um instante e perguntei, "Quer escrever um livro comigo sobre Equipes Ágeis distribuídas?"

Mark Kilby: Demorei muito tempo para pensar sobre isso (cerca de meio milissegundo) e disse: "Sim! Vamos fazer isso". Foi quando nossa jornada como equipe de redação distribuída começou.

Rothman: Fiz esta pergunta ao Kilby, pois tive clientes que pensavam estar trabalhando no mesmo local, mas não estavam. Pior que isso, trabalhei com clientes que, apesar de distribuídos, achavam que poderiam trabalhar da mesma maneira que uma equipe alocada no mesmo espaço. Nenhuma dessas pessoas conseguiu fazer com que a abordagem ágil preferida deles funcionasse.

Kilby: Trabalhei com muitas equipes e empresas que possuíam especialistas valiosos em vários locais. Alguns tinham experiências anteriores com o ágil e outros nem tanto. Eles queriam os benefícios do ágil sem precisar realocar todas as pessoas. Algumas dessas equipes executam projetos de código aberto e tiveram a experiência de trabalhar remotamente. O que todos queriam era simplesmente melhorar a comunicação e a colaboração.

O que o ágil deu a eles foi uma maneira de repensar o jogo do desenvolvimento distribuído.

Rothman e Kilby (costumamos dizer isso juntos!): Equipes distribuídas pensavam que poderiam usar exatamente as mesmas práticas das equipes alocadas. Isso era um problema e queríamos resolver, além de ajudá-las a trabalhar melhor.

InfoQ: Parece que cada vez mais as empresas, quer sejam ágeis ou não, estão usando equipes distribuídas. O que está impulsionando essa tendência? Isso seria um problema?

Kilby: Na Sonatype, onde estou trabalhando atualmente, começamos especificamente com equipes distribuídas, a fim de ter os melhores talentos de todo o mundo. Os produtos cresceram a partir do ecossistema open source. Portanto, muitas pessoas entendiam como trabalhar efetivamente de maneira remota.

Queríamos também, usar ao máximo os princípios e práticas ágeis para que os membros da equipe pudessem colaborar com rapidez e facilidade. Eles sabiam que estariam em um mercado de rápida mudança e queriam usar o ágil para responder rapidamente a este mercado.

Rothman: Alguns dos meus clientes tinham motivos diferentes. Queriam facilitar a vida das pessoas que moravam nas áreas metropolitanas, diminuindo o tempo que passavam dentro dos carros indo e voltando do trabalho, ou não gastando todo o seu dinheiro para morar próximo ao trabalho.

Alguns dos gerentes também queriam resiliência na empresa. Quanto mais disperso estivermos, assumindo que todos tenham uma infraestrutura razoável, mais resilientes serão as equipes e, portanto, a empresa também. Alguns dos colaboradores estão enfrentando condições climáticas extremas em algum lugar, como nevascas, ou furacões? É bem provável que outros não estejam experienciando o mesmo clima.

Vemos um problema em potencial: Pensamos que uma equipe distribuída irá diminuir os custos. Ninguém conseguiu confirmar a veracidade desta suposição. Quanto menos horas de overlap (quando os membros com fuso horários diferentes estão trabalhando ao mesmo tempo) a equipe tiver, maior o tempo do ciclo. Quanto maior o tempo do ciclo, maior a duração e mais caro se torna o projeto.

Portanto, não, equipes distribuídas não são um problema, porque agora temos ferramentas suficientes para a comunicação e colaboração. No entanto, quando os gerentes se concentram na eficiência dos recursos, frequentemente ñão enxergam o valor das pessoas que fazem o trabalho.

InfoQ: Existem alguns padrões comuns para equipes distribuídas e quais são as características dos diferentes tipos?

Kilby: Vemos três padrões básicos para equipes distribuídas:

As equipes Satélites tem a maioria dos membros alocados no mesmo lugar e poucas pessoas remotas. Geralmente, as pessoas remotas trabalham em casa. Normalmente, este padrão surge quando temos programas de home office ou temos um membro da equipe cujo cônjuge encontra uma oportunidade em outra cidade. Nesse último caso, o funcionário pode estar preparado para deixar a empresa, mas são tão valorizados que têm a oportunidade de trabalhar remotamente.

As equipes Clusters surgem quando temos subgrupos de equipe em locais diferentes. Isso pode ocorrer por função (proprietário do produto, scrum masters, desenvolvedores, controle de qualidade etc.), ou pode ser um arranjo mais aleatório. A diferença é que a maioria da equipe não está em um único local.

Rothman: Muitas vezes, vemos alguns desenvolvedores em um local, alguns testadores em outro, um PO (Product Owner) em um terceiro local e, possivelmente, um gerente de projeto ágil ou Scrum Master ou coach, em um quarto local.

Kilby: O terceiro tipo de padrão é a Nebulosa. Todos estão dispersos. Ninguém compartilha um escritório e a colaboração de todos é sempre online.

Podem existir combinações híbridas desses padrões, mas ainda assim veremos esses três padrões.

Rothman: Observe que todos os nomes possuem uma referência ao espaço. O que não temos em uma equipe distribuída é o espaço físico. O que precisamos é trazer o continuum do espaço-tempo para a equipe.

InfoQ: Quais são os desafios específicos que as equipes distribuídas enfrentam quando tentam trabalhar de maneira ágil?

Kilby: Um dos maiores desafios ocorre quando agilistas experientes tentam aplicar nas equipes distribuídas as mesmas práticas que aplicam nas equipes locais. Uma prática típica, como a retrospectiva pode se tornar complicada e dolorosa, dependendo da distribuição dos membros e das horas de overlap.

Em vez disso, recomendamos voltar aos princípios e ver como as práticas que desejamos usar tentavam aplicar esses princípios.

Como os princípios podem vir a sugerir práticas diferentes para o nosso contexto a fim de alcançarmos o mesmo objetivo?

Rothman: Para uma retrospectiva, quanto podemos fazer de forma assíncrona na preparação da reunião e quanto precisamos fazer juntos? Mark [Kilby] tem uma vasta experiência com a preparação assíncrona e discussões síncronas.

Talvez a equipe tenha um pequeno evento de kaizen todos os dias, especialmente se não tiverem muitas horas de overlap. Talvez o time só tenha retrospectivas quando estiverem juntos, uma vez a cada trimestre.

InfoQ: Que mudanças as equipes distribuídas precisam fazer para usar uma abordagem ágil? Podem usar o Scrum padrão?

Rothman: As equipes ágeis distribuídas raramente podem lançar mão de uma abordagem padrão, como o Scrum, que especificamente, possui muitos rituais em tempo real. Muitas equipes acham que passam muito tempo em reuniões. Esses rituais não fazem sentido para uma equipe distribuída.

Em vez disso, se as equipes usam os princípios ágeis e enxutos e adaptam as práticas ao seu contexto, é muito mais provável que tenham sucesso.

Aqui está o maior desafio que vejo, especificamente no Scrum: Quando a iteração começa e quando termina?

Se tivermos seis horas de overlap, isso pode ser apenas um acordo de trabalho entre os membros da equipe. Mas e tivermos apenas quatro horas de overlap? O que as pessoas que estão no oeste fazem quando a iteração "termina"? Quando fazem a demonstração? Quando conduzem uma retrospectiva? Na verdade, não vejo como gerenciar o Scrum quando temos menos de seis horas de overlap. Sim, isso significa que, se tiver membros da equipe espalhados por diferentes fuso horários, recomendo que não use o Scrum.

Existem muitos outros desafios. A maioria deles ocorre porque a equipe não tem horas suficientes de overlap.

InfoQ: "Horas de overlap" foram mencionadas algumas vezes. Por que a ênfase nisso?

Kilby: Muitas pessoas falam sobre os fusos horários e como isso nos separa. Mas já estive com profissionais que preferiam trabalhar mais cedo ou mais tarde no dia local para poderem colaborar com o restante dos membros da equipe.

E trabalhei com nômades digitais. São pessoas que viajam pelo mundo, moram em algum lugar por um tempo e depois se mudam para outro. Essas pessoas decidem quando trabalharão, para que possam trabalhar com a equipe.

Os fusos horários não importam. As horas de overlap sim.

Rothman: Quando Mark [Kilby] disse pela primeira vez a frase "Horas de overlap", tive aquele momento de Eureka. Sabe quando escutamos uma pessoa falar uma frase que expressa exatamente aquilo que queremos dizer? Então tudo o que tivemos que fazer foi mostrar o que aquelas palavras significavam.

Já usei gráficos de bolhas de fuso horário antes. Estes funcionam bem quando não estamos mudando para o horário padrão, ou saindo dele. Mas não funcionam nas seguintes condições:

• Quando o país ou estado muda para o horário de verão. Todos os países parecem mudam de acordo com a própria agenda. E alguns estados não mudam absolutamente nada.

• Quando as pessoas preferem trabalhar mais cedo ou mais tarde e isso funciona bem para a equipe.

• Quando as pessoas têm obrigações diurnas que as afastam do trabalho. Mesmo que seja algo intermitente como uma consulta médica de uma criança, se houver um gráfico semanal de Horas de overlap, todos poderão ver o efeito na equipe.

As horas do gráfico de overlap são como um radiador de informações. Elas dizem à equipe quando podemos trabalhar juntos.

InfoQ: Existem exemplos de empresas que alcançaram uma colaboração eficaz com equipes distribuídas? Se sim, o que fizeram para chegar neste resultado?

Kilby: Existem vários exemplos. A Automattic, que desenvolve a plataforma de blogs Wordpress. O Gitlab, que constrói plataformas de desenvolvimento de software para equipes distribuídas. Além disso, a empresa em que trabalho, Sonatype, tem utilizado com sucesso as práticas ágeis em equipes distribuídas nos últimos 6 anos e tinha pequenas equipes de colaboração antes disso.

Pela minha experiência na Sonatype e em outras empresas, e pelo que li sobre empresas como Automattic e Gitlab, várias conseguiram essa colaboração distribuída dando o direito de escolha aos funcionários, sendo muito transparentes com eles e desejando experimentar novas maneiras de trabalhar.

Outra maneira de explicar o sucesso: Elas confiam que os funcionários trabalham para o melhor da empresa, mesmo que não possam vê-los todos os dias.

Rothman: A Particular Software é uma organização 100% distribuída (uma nebulosa se colocarmos nos termos que criamos). Eles alcançam a colaboração usando ferramentas técnicas, como o Github, e também através de ferramentas como o Zoom.

Um dos valores da empresa é o que chamam de "maturidade na interação". Isso significa que dão feedback um ao outro e retrospectiva sobre o trabalho. Eu chamaria isso de inspecionar e adaptar em todas as situações: Como colaboram para produzir o trabalho, as interações para essa colaboração, o próprio trabalho (processo e produto).

Aqui está o que notei: Eles são um time em tudo. Não fazem quase nada como indivíduos. Dizem: "Nosso sucesso trabalhando remotamente é uma função de TODOS trabalhando remotamente, das ferramentas que usamos e como as usamos, dos nossos valores e da cultura que criamos cuidadosamente ao longo do tempo. E, é claro, a qualidade das pessoas que contratamos".

Por adotarem o trabalho colaborativo e criarem transparência em torno de tudo, podem se comunicar de maneira efetiva.

InfoQ: Como os líderes devem se envolver e apoiar as equipes quando estas são distribuídas?

Rothman: Recomendamos que todos comecem com essas três mudanças de mentalidade:

Mentalidade 1. Gerenciar para mudar. Isso significa experimentar.

Mentalidade 2. Enfatizar a comunicação e a colaboração.

Mentalidade 3. Usar princípios ágeis, não práticas.

Quando os líderes adotam essas mentalidades, trazem otimização para a equipe concentrando-se na eficiência do fluxo. Os líderes não se concentram na eficiência dos recursos, otimizando para o indivíduo.

Os líderes removem os impedimentos "remotos" típicos, como acesso insuficiente à infraestrutura, ou licenças, ou permissões insuficientes para as diversas ferramentas. E, quando os líderes usam princípios ágeis, não consideram a tentativa de padronizar em quadros ou estruturas para as equipes.

Se uma empresa deseja os benefícios das equipes ágeis distribuídas, toda a liderança deve adotar essas mentalidades. Essa é uma grande mudança.

Kilby: Devemos sempre iniciar com pequenos experimentos. Decida o que deseja alterar. Que orientação podemos obter de um princípio ágil ou Lean? Como isso se aplica ao contexto remoto? Não tente replicar uma prática de uma equipe local em um ambiente remoto. Isso muito provavelmente irá falhar. Frequentemente, a pequena mudança pode ser apresentar uma nova prática alinhada aos princípios ágeis e enxutos. Discuta o experimento proposto com os interessados ​​e impactados para obter ideias sobre como melhor executá-lo.

Depois de iniciar o "experimento", execute-o por um curto período de tempo (dias ou algumas semanas) e verifique se pode receber comentários daqueles que estão envolvidos. Essa é outra área em que a comunicação e a colaboração entram em cena. O que observamos? O que funcionou bem? O que nos surpreendeu? Provamos o que nos propusemos a provar?

Quando a equipe, ou empresa, se acostumar a pequenas experiências, poderemos arriscar uma mudança maior. Uma empresa que trabalhei como coach começou com sessões de perguntas e respostas sobre lean, durante o café da manhã, a cada duas semanas, para ajudar a conectar as pessoas de toda a empresa de maneira informal. O formato tornou-se tão popular para a construção de relacionamentos em toda a empresa, que realizamos um experimento maior com reuniões mais completas. Como todos na empresa deveriam comparecer fisicamente por alguns dias durante essas reuniões e nunca conseguimos definir uma agenda que satisfizesse a todos, tentamos um formato de espaço aberto. A empresa usou essa abordagem nos últimos quatro anos, com grande sucesso em levantar questões importantes, planejar novas iniciativas e construir conexões mais fortes entre as equipes.

Sobre os autores

Johanna Rothman, conhecida como "Gerente Pragmática", fornece conselhos francos para os problemas difíceis. Ajuda líderes e equipes a encontrar problemas, diminuir os riscos e gerenciar o desenvolvimento dos produtos. Rothman foi o presidente da conferência do Agile 2009 e co-presidente da primeira edição do Guia do Agile Practice. Rothman é autora de 14 livros que variam de contratação a gerenciamento de projetos, gerenciamento de programas, gerenciamento de portfólio de projetos e gerenciamento no geral. Seus livros mais recentes são From Chaos to Successful Distributed Agile Teams (com Mark Kilby) e Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. Está trabalhando em livros sobre gestão moderna. Leia mais sobre seu trabalho aqui e aqui.

Mark Kilby, com mais de duas décadas de experiência em princípios e práticas ágeis, cultivou equipes mais distribuídas e dispersas do que equipes alocadas. Foi consultor de empresas de vários setores e treinou equipes, líderes e organizações internamente. Kilby também co-fundou uma série de empresas de aprendizado profissional, como o Agile Orlando, o Agile Florida, o Virtual Team Talk e a Agile Alliance Community Group Initiative, entre outros. Seu estilo descontraído ajuda as equipes a aprender a colaborar e a descobrir o caminho para o sucesso e a sustentabilidade. Leia suas ideias e artigos mais recentes aqui.