Como uma organização pode promover fluidez entre seus times sem comprometer a coesão interna das equipes, as relações com clientes, a qualidade e o ritmo das entregas? O post anterior tentou explicar a motivação para este movimento. É hora de conversar sobre como ele pode ser feito.Que o profissional possa conhecer todas as alternativas e escolher o projeto, processo ou produto onde trabalhar é requisito tanto óbvio quanto raro, particularmente em terras tupiniquins. Normalmente contratamos para uma posição pré-determinada. Quase sempre para apagar incêndios. A inexistência de testes – de um onboarding minimamente planejado – explica boa parte dos problemas que testemunhamos desde sempre. Essa mentalidade mecanicista – a peça que deve porque deve se encaixar em dado mecanismo – tem poucas chances de sucesso em trabalhos criativos. E este é só o começo da história.
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
- A dupla se encontra diariamente
- O encontro dura entre uma e duas horas
(Claro, a dupla tem autonomia para definir o melhor momento) - A cada dia ou semana eles atuam em um dos dois projetos
- Eles paream, ou seja, trabalham juntos em uma mesma história ou item do backlog
- 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 Plugin4.
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
- Conecte o time Plugin ao time hospedeiro
- O acoplamento deve ser muito suave. Leia-se: os hábitos e rotinas do time hospedeiro não devem ser alterados
- 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
- Se o objetivo é uma substituição, então
- 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
- Isso é possível porque o novato realmente trabalhou naquele projeto, orientado inicialmente pelo tutor e depois por membros do time principal com quem pareou
- 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
- Um mal muito bem documentado em The Silo Effect, de Gillian Tett (Simon & Schuster, 2016).
- 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.
- 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.
- 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.
- Foto de Karim Ghantous no Unsplash
