Porque, nos atos seguintes, trabalhamos pela manutenção daquela estrutura. Não vou negar o que escrevi no artigo anterior: devemos premiar as equipes duradouras. Faltou alertar: desde que tenhamos ciência e antídotos para os riscos que elas representam. 

Um time com estrutura estável tende a ter uma forte coesão interna (bonding). Se essa estrutura for pouco porosa – de poucas trocas com outras equipes (baixo building) – ela se torna um silo. Pois é, uma estrutura moderna – multidisciplinar, autônoma e bem alinhada – está sujeita ao mesmo mal que aflige as unidades funcionais das organizações tradicionais: se transformar num silo que pouco colabora e não raro atua como se fosse o fim e não apenas um meio¹. 

O alto nível de building – de convivência e trocas constantes entre times – é a principal condição para o desenho de uma organização flexível. Se o building é alto, os profissionais vão transitar com mais facilidade entre os diversos times². 

Guildas e Capítulos

Não é por outra razão que não seja a promoção do building a presença de guildas e capítulos no modelo Spotify. Essas formações visam a troca de experiências e conhecimentos. São releituras pouco criativas das Comunidades de Prática, outra ideia elegante, simples e pouco eficaz na promoção de trocas entre times. Essas propostas são fracas para o building porque:

• seus encontros são esporádicos (os ciclos de feedback são longos);
• geralmente envolvem muita gente (12+ é muita gente);
• têm sérias restrições de tempo;
• favorecem temas amplos visando atender o maior número possível de colegas, o que aumenta o risco de papos superficiais e pouco práticos;
• muitos usam os formatos de palestra, aula ou demonstração. Leia-se: há grande risco de tédio, alienação, papos paralelos etc. 

Ou seja, essas estruturas são caras, de difícil implantação e com resultados no mínimo duvidosos. Apesar do início promissor, da motivação natural que vem das coisas novas, esses grupos tendem ao esvaziamento em poucos meses. O building pede por desenhos mais criativos e ambiciosos.

Desenhando o Intercâmbio entre Times

Uma das receitas mais enxutas e promissoras é o Pareamento Promíscuo³ ou Pareamento Cruzado. É simples pra chuchu.

Ingrediente: Um par, sendo cada membro de um time diferente

Modo de uso

1. A dupla se encontra diariamente
2. O encontro dura entre uma e duas horas
   (Claro, a dupla tem autonomia para definir o melhor momento)
3. A cada dia ou semana eles atuam em um dos dois projetos
4. Eles paream, ou seja, trabalham juntos em uma mesma história ou item do backlog
5. Este casamento deve durar pelo menos um mês. E não mais do que dois ou três meses, dependendo da complexidade dos domínios envolvidos.

O trabalho em pares, uma prática essencial da XP (eXtreme Programming), não é uma exclusividade dos desenvolvedores. Designers, analistas e zagueiros também podem trabalhar em duplas. Por que não? Como não?

Preciso me distanciar da ideia para fazer uma avaliação mais isenta. Porque, neste momento, vejo só benefícios: o potencial do olhar de fora para descobrir novas possibilidades; o refresco da troca de contexto; a possibilidade de trabalhar em outro domínio e/ou com outras tecnologias e ferramentas; além, claro, da intenção original da polinização cruzada. Tudo isso a custo zero? Pois é, parece bom demais para ser verdade. O que estou ignorando?

Uma estrutura tão promissora e rica mas não tão econômica quanto a sugerida acima é o Time Plugin⁴.

Ingredientes

• O time Plugin formado por 2+ profissionais que não estejam alocados em nenhum projeto específico.
• Se envolver um processo de onboarding, então os integrantes do Plugin são um tutor (coach não, tutor! – alguém que senta, ensina pareando e entrega) e pelo menos um novato (na organização, não necessariamente na profissão)
• Um time hospedeiro. A equipe ideal deve ter pelo menos uma das seguintes características:
  – Um ou mais membros prestes a sair do time em caráter temporário (férias ou licença programada) ou permanente
  – Código relativamente antigo (2+ anos)
  – Um cliente que há tempo (12+ meses) só demanda mais do mesmo

Modo de Uso

1. Conecte o time Plugin ao time hospedeiro
2. O acoplamento deve ser muito suave. Leia-se: os hábitos e rotinas do time hospedeiro não devem ser alterados
3. O time Plugin pode ou não participar das cerimônias (dailys, retros, reviews etc). A palavra final é do time hospedeiro ou de seu cliente
4. Se o objetivo é uma substituição, então
5. Após 15~30 dias de conexão, espera-se que o membro novato tenha condições de assumir uma posição, qualquer posição, no time principal
6. Isso é possível porque o novato realmente trabalhou naquele projeto, orientado inicialmente pelo tutor e depois por membros do time principal com quem pareou
7. No início da conexão, pelo menos por duas semanas, é indicado que o novato atue exclusivamente em refatoração. Depois, oportunamente, ele pode se aventurar em itens novos ou até mesmo participando de alguns experimentos (spikes).

Casos de Uso

Um time plugin pode oferecer diversas funcionalidades para uma organização:

• Cobertura de férias e licenças.
• Substituição permanente de membros.
• Área de onboarding: região segura onde um novo colaborador pode ser acomodado para entender o que é trabalhar naquela organização (cultura, métodos, ferramentas etc). Neste caso, a estrutura deve ser plugada nos diversos times existentes. Recomenda-se conexões com duração mínima de uma semana. Claro, desde que isso não resulte em meses e meses de onboarding.
• Refatoração Oportunista: todas as refatorações são oportunistas de alguma forma. Aqui a intenção parece ser outra: a cobertura de férias, por exemplo. A usamos como desculpa para dar um belo tapa (por 15 ou 30 dias!) no código. O cliente fica duplamente agradecido: pela manutenção da estrutura do time e pelo código que ganhou um banho de loja a custo zero.
• Spikes Interesseiros: há tempo o cliente não desafia o time principal. O relacionamento caiu na rotina. Há o risco do cliente cancelar ou pedir pela redução do contrato. É chegada a hora do código vendedor. Que o time plugin faça pesquisas e experimentos (spikes) na esperança de descobrir novas oportunidades de negócio para aquele cliente. Esta proatividade tende a render, no mínimo, uma boa surpresa e ótima impressão. 

Quanto maior a rotatividade no time plugin, maior o nível de building alcançado. Quanto ele custa? Cerca de 10% de sua folha de pagamento atual, se houver a intenção de cobrir férias. Não é uma estrutura barata. Por isso é importante que ela seja rica em termos de funcionalidades oferecidas. 

Nada impede que você mantenha as guildas e capítulos enquanto testa as duas sugestões acima. Não há conflito. E você ganha a possibilidade de fazer uma comparação mais objetiva dos benefícios e custos de cada estrutura. Se você o fizer, por favor, não deixe de compartilhar. Os desenhos sugeridos acima foram testados em apenas uma organização. Há outras referências (veja notas abaixo), mas nada substitui a validação no mundo real, com times de verdade. Se você quer conversar mais sobre as ideias e não gosta do formato assíncrono, considere a participação em uma edição da aula sobre Grandes TIMES Pequenos. Se pretende colocar as ideias para rodar e quer alguma orientação, conte comigo.

Notas

1. Um mal muito bem documentado em The Silo Effect, de Gillian Tett (Simon & Schuster, 2016).
2. Bonding (coesão entre membros de um time), Building (desenvolvimento de parcerias com outros times) e Believing (confiança na organização) são os três tipos de Capital Social apresentados por Robert Bruce Shaw em Extreme Teams (Amacom, 2017). A matriz sugerida acima não é de Shaw. Sua elaboração é possível através de pesquisas internas. O building pode ser capturado através de duas perguntas: 1) Com que frequência você aprende coisas com outros times; e 2) Com que frequência você tem a oportunidade de ensinar coisas para membros de outros times.
3. Na versão original, citada por Scott Ambler em Beautiful Teams (O’Reilly, 2009), a promiscuidade é total: os casais são trocados todo santo dia. A diferença é que todos atuam no mesmo produto / projeto. Na versão aqui sugerida os participantes são necessariamente de times diferentes. E o par não é trocado diariamente. Caso contrário, não há building. A versão aqui apresentada recebeu colaborações inestimáveis de Altieres Lopes, Will Marcondes, Klaus Wuestefeld e grande elenco.
4. Pode ser confundido com os times capacitadores (enabling) propostos por Matthew Skelton e Manuel Pais em Team Topologies (IT Revolution Press, 2019). A versão aqui sugerida é um tanto mais ambiciosa em termos de funcionalidades oferecidas.
5. Foto de Karim Ghantous no Unsplash

Porque, nos atos seguintes, trabalhamos pela manutenção daquela estrutura. Não vou negar o que escrevi no artigo anterior: devemos premiar as equipes duradouras. Faltou alertar: desde que tenhamos ciência e antídotos para os riscos que elas representam. 

Um time com estrutura estável tende a ter uma forte coesão interna (bonding). Se essa estrutura for pouco porosa – de poucas trocas com outras equipes (baixo building) – ela se torna um silo. Pois é, uma estrutura moderna – multidisciplinar, autônoma e bem alinhada – está sujeita ao mesmo mal que aflige as unidades funcionais das organizações tradicionais: se transformar num silo que pouco colabora e não raro atua como se fosse o fim e não apenas um meio¹. 

O alto nível de building – de convivência e trocas constantes entre times – é a principal condição para o desenho de uma organização flexível. Se o building é alto, os profissionais vão transitar com mais facilidade entre os diversos times². 

Guildas e Capítulos

Não é por outra razão que não seja a promoção do building a presença de guildas e capítulos no modelo Spotify. Essas formações visam a troca de experiências e conhecimentos. São releituras pouco criativas das Comunidades de Prática, outra ideia elegante, simples e pouco eficaz na promoção de trocas entre times. Essas propostas são fracas para o building porque:

• seus encontros são esporádicos (os ciclos de feedback são longos);
• geralmente envolvem muita gente (12+ é muita gente);
• têm sérias restrições de tempo;
• favorecem temas amplos visando atender o maior número possível de colegas, o que aumenta o risco de papos superficiais e pouco práticos;
• muitos usam os formatos de palestra, aula ou demonstração. Leia-se: há grande risco de tédio, alienação, papos paralelos etc. 

Ou seja, essas estruturas são caras, de difícil implantação e com resultados no mínimo duvidosos. Apesar do início promissor, da motivação natural que vem das coisas novas, esses grupos tendem ao esvaziamento em poucos meses. O building pede por desenhos mais criativos e ambiciosos.

Desenhando o Intercâmbio entre Times

Uma das receitas mais enxutas e promissoras é o Pareamento Promíscuo³ ou Pareamento Cruzado. É simples pra chuchu.

Ingrediente: Um par, sendo cada membro de um time diferente

Modo de uso

1. A dupla se encontra diariamente
2. O encontro dura entre uma e duas horas
   (Claro, a dupla tem autonomia para definir o melhor momento)
3. A cada dia ou semana eles atuam em um dos dois projetos
4. Eles paream, ou seja, trabalham juntos em uma mesma história ou item do backlog
5. Este casamento deve durar pelo menos um mês. E não mais do que dois ou três meses, dependendo da complexidade dos domínios envolvidos.

O trabalho em pares, uma prática essencial da XP (eXtreme Programming), não é uma exclusividade dos desenvolvedores. Designers, analistas e zagueiros também podem trabalhar em duplas. Por que não? Como não?

Preciso me distanciar da ideia para fazer uma avaliação mais isenta. Porque, neste momento, vejo só benefícios: o potencial do olhar de fora para descobrir novas possibilidades; o refresco da troca de contexto; a possibilidade de trabalhar em outro domínio e/ou com outras tecnologias e ferramentas; além, claro, da intenção original da polinização cruzada. Tudo isso a custo zero? Pois é, parece bom demais para ser verdade. O que estou ignorando?

Uma estrutura tão promissora e rica mas não tão econômica quanto a sugerida acima é o Time Plugin⁴.

Ingredientes

• O time Plugin formado por 2+ profissionais que não estejam alocados em nenhum projeto específico.
• Se envolver um processo de onboarding, então os integrantes do Plugin são um tutor (coach não, tutor! – alguém que senta, ensina pareando e entrega) e pelo menos um novato (na organização, não necessariamente na profissão)
• Um time hospedeiro. A equipe ideal deve ter pelo menos uma das seguintes características:
  – Um ou mais membros prestes a sair do time em caráter temporário (férias ou licença programada) ou permanente
  – Código relativamente antigo (2+ anos)
  – Um cliente que há tempo (12+ meses) só demanda mais do mesmo

Modo de Uso

1. Conecte o time Plugin ao time hospedeiro
2. O acoplamento deve ser muito suave. Leia-se: os hábitos e rotinas do time hospedeiro não devem ser alterados
3. O time Plugin pode ou não participar das cerimônias (dailys, retros, reviews etc). A palavra final é do time hospedeiro ou de seu cliente
4. Se o objetivo é uma substituição, então
5. Após 15~30 dias de conexão, espera-se que o membro novato tenha condições de assumir uma posição, qualquer posição, no time principal
6. Isso é possível porque o novato realmente trabalhou naquele projeto, orientado inicialmente pelo tutor e depois por membros do time principal com quem pareou
7. No início da conexão, pelo menos por duas semanas, é indicado que o novato atue exclusivamente em refatoração. Depois, oportunamente, ele pode se aventurar em itens novos ou até mesmo participando de alguns experimentos (spikes).

Casos de Uso

Um time plugin pode oferecer diversas funcionalidades para uma organização:

• Cobertura de férias e licenças.
• Substituição permanente de membros.
• Área de onboarding: região segura onde um novo colaborador pode ser acomodado para entender o que é trabalhar naquela organização (cultura, métodos, ferramentas etc). Neste caso, a estrutura deve ser plugada nos diversos times existentes. Recomenda-se conexões com duração mínima de uma semana. Claro, desde que isso não resulte em meses e meses de onboarding.
• Refatoração Oportunista: todas as refatorações são oportunistas de alguma forma. Aqui a intenção parece ser outra: a cobertura de férias, por exemplo. A usamos como desculpa para dar um belo tapa (por 15 ou 30 dias!) no código. O cliente fica duplamente agradecido: pela manutenção da estrutura do time e pelo código que ganhou um banho de loja a custo zero.
• Spikes Interesseiros: há tempo o cliente não desafia o time principal. O relacionamento caiu na rotina. Há o risco do cliente cancelar ou pedir pela redução do contrato. É chegada a hora do código vendedor. Que o time plugin faça pesquisas e experimentos (spikes) na esperança de descobrir novas oportunidades de negócio para aquele cliente. Esta proatividade tende a render, no mínimo, uma boa surpresa e ótima impressão. 

Quanto maior a rotatividade no time plugin, maior o nível de building alcançado. Quanto ele custa? Cerca de 10% de sua folha de pagamento atual, se houver a intenção de cobrir férias. Não é uma estrutura barata. Por isso é importante que ela seja rica em termos de funcionalidades oferecidas. 

Nada impede que você mantenha as guildas e capítulos enquanto testa as duas sugestões acima. Não há conflito. E você ganha a possibilidade de fazer uma comparação mais objetiva dos benefícios e custos de cada estrutura. Se você o fizer, por favor, não deixe de compartilhar. Os desenhos sugeridos acima foram testados em apenas uma organização. Há outras referências (veja notas abaixo), mas nada substitui a validação no mundo real, com times de verdade. Se você quer conversar mais sobre as ideias e não gosta do formato assíncrono, considere a participação em uma edição da aula sobre Grandes TIMES Pequenos. Se pretende colocar as ideias para rodar e quer alguma orientação, conte comigo.

Notas

1. Um mal muito bem documentado em The Silo Effect, de Gillian Tett (Simon & Schuster, 2016).
2. Bonding (coesão entre membros de um time), Building (desenvolvimento de parcerias com outros times) e Believing (confiança na organização) são os três tipos de Capital Social apresentados por Robert Bruce Shaw em Extreme Teams (Amacom, 2017). A matriz sugerida acima não é de Shaw. Sua elaboração é possível através de pesquisas internas. O building pode ser capturado através de duas perguntas: 1) Com que frequência você aprende coisas com outros times; e 2) Com que frequência você tem a oportunidade de ensinar coisas para membros de outros times.
3. Na versão original, citada por Scott Ambler em Beautiful Teams (O’Reilly, 2009), a promiscuidade é total: os casais são trocados todo santo dia. A diferença é que todos atuam no mesmo produto / projeto. Na versão aqui sugerida os participantes são necessariamente de times diferentes. E o par não é trocado diariamente. Caso contrário, não há building. A versão aqui apresentada recebeu colaborações inestimáveis de Altieres Lopes, Will Marcondes, Klaus Wuestefeld e grande elenco.
4. Pode ser confundido com os times capacitadores (enabling) propostos por Matthew Skelton e Manuel Pais em Team Topologies (IT Revolution Press, 2019). A versão aqui sugerida é um tanto mais ambiciosa em termos de funcionalidades oferecidas.
5. Foto de Karim Ghantous no Unsplash

Que seja eterno enquanto gerar resultados

Que seja eterno enquanto promover relacionamentos saudáveis e inspiradores. Não parece haver uma idade ideal para times. Nem pesquisas minimamente abrangentes sobre o assunto. Seria fácil chutar algo entre um e quatro anos. Dadas a velocidade das mudanças e a reincidência dos timecídios, parecem anacrônicos os times que conseguem sobreviver por mais de doze meses.

Configura-se um timecídio o desmanche de um time que estava gerando valor de facto ou demonstrava potencial para fazê-lo. Além do grande desconforto gerado, para os integrantes do time e para todos que se relacionavam com ele, um timecídio é causa clara e nunca contabilizada de grandes desperdícios. Porque aquele capital social – a coesão interna entre membros do time e as relações de confiança construídas com entes externos – não caiu do céu nem custou barato. E porque, claro, aquele ritmo de entrega de valor foi quebrado e pode demorar para ser retomado. 

Assim como devemos incentivar a cooperação², faz sentido que a gente celebre e até mesmo premie os times longevos. Isso é facilitado quando a empresa se organiza em torno de produtos e não de projetos. 

A Estabilidade Requerida

Nesses tempos líquidos, quanta estabilidade é possível? E quanta estabilidade é desejável? 

Há tempo nos ensinam que a aquisição de novos clientes é seis vezes mais cara do que a manutenção de um. É bem possível que essa conta esteja defasada. Porque, aparentemente, a infidelidade da freguesia só faz aumentar. 

Um time estável tende a aumentar a intimidade da organização com seus clientes e usuários. A confiança aumenta. É um ciclo virtuoso que deve ser motivado. Porque é mais fácil atender um cliente bem conhecido; Porque fica mais difícil perder um cliente bem atendido. Nesses tempos de vacas magérrimas, perder clientes por conta de mau atendimento/entendimento é um luxo só. 

Portanto, se não por outros motivos, a estabilidade de um time é desejável por significar relacionamentos melhores e mais estáveis com clientes. O que é um tanto mais notável e caro, mas não exclusivo, em empresas prestadoras de serviços. 

A Instabilidade Inevitável

Até que ponto as pessoas querem amarrar sua carreira a um produto ou linha de produtos? Quantos, hoje, topariam vincular sua evolução à permanência em uma mesma organização? A infidelidade é regra. E erram feio – feio em mais de um sentido – aqueles que atribuem apenas ao dinheiro a razão para tanta volatilidade. 

Muita gente, conscientemente ou não, busca variedade. Elas querem assuntos, funções e responsabilidades diferentes. Há mais opções supostamente mais atraentes a cada dia. É um mal dos nossos tempos o medo de ficar de fora³. Não será através de chantagens ou doping – os viciantes bônus, prêmios e promoções – que conseguiremos a motivação e consequente lealdade de um time. Ou seja, aquela estabilidade requerida pelas organizações raramente encontrará respaldo nos planos das pessoas. 

Nem sempre foi assim. Nossos pais e avós contam com orgulho a história de uma vida profissional que se desenvolveu em apenas uma ou duas empresas; Em um mundo que não existe mais. Ao  invés de cobrar por uma fidelidade impossível, as organizações precisam ser desenhadas não apenas para acomodar mas para incentivar essa fluidez. 

Como? 

Notas

1. Definição de Zygmunt Bauman, em livro homônimo (Zahar, 2007), para os nossos tempos de extremas incertezas.
2. Em uma das edições da conversa sobre Grandes TIMES Pequenos rolou um debate sobre o uso do termo cooperação em detrimento de colaboração. Opto pelo primeiro desde que aprendi que co-opera, do original em latim, significa comprometimento com o resultado. Co-labora, também do latim, refere-se ao trabalho em equipe, no mesmo local, ombro a ombro – mas não fala sobre resultados. A distinção é bem didática em Six Simple Rules, de Yves Morieux e Peter Tollman (HBR, 2014).
3. Fear of Missing Out, ou FoMO, no original em inglês. Na Wikipédia: https://pt.wikipedia.org/wiki/S%C3%ADndrome_de_FOMO
4. Foto de Devon Janse van Rensburg no Unsplash.