Topologia e estabilidade de times
Vamos falar sobre um tema controverso entre os agilistas?
por Pedro Barillo, engenheiro de formação, curioso por definição, contribuindo na transformação digital do Itaú-Unibanco.
Quando falamos de “times ágeis”, um dos assuntos que sempre vem a tona é o tema da estabilidade destes times. Você pode chamar o time de Squad, Pod, Célula, entre muitos outros nomes, mas há um certo consenso na definição de times ágeis: “Times multidisciplinares com um propósito comum”. Ou seja, um time composto por membros com diversos backgrounds e conhecimentos necessários para atingir um determinado objetivo.
Exploraremos mais esta definição em outras publicações onde falaremos sobre gestão por resultados, mas por hora podemos simplificar o entendimento em: Times de Produto vs Times de Projeto. Ambos podem ser “times ágeis”, onde o primeiro é aquele time cujo escopo é descobrir, construir e manter um “produto”, o segundo é aquele cujo escopo é entregar um projeto. Não me entenda mal, eu não sou do time morte-aos-projetos. Pelo contrário, acredito que em algumas situações times de projeto podem ser uma ótima solução. No entanto, pela própria definição acima descrita, podemos interpretar que times de produto são mais perenes e portanto intrinsecamente melhores. Mas será que é isso mesmo?
Topologia, um tema muito extenso.
Como você deve ter reparado pelo título, o tema de estabilidade de times, ao meu ver, faz parte de um outro tema mais abrangente, a Topologia de Times. Meu intuito neste primeiro artigo não é abranger todos os detalhes sobre Topologia (até porquê não caberia em uma única publicação), mas sim explorar a estabilidade como o aspecto dinâmico da Topologia, entendendo como a estabilidade afeta o dia-a-dia das pessoas e os resultados da organização. Falaremos mais sobre Topologia em futuras publicações!
Afinal, o que é um time?
Umas das definições mais comuns do termo time é a seguinte: “Um grupo estável de pessoas que atuam em conjunto com um mesmo objetivo em mente”. Essa definição se aplica ao trabalho feito em corporações, aos esportes, na política, etc.
O tipo mais simples de times é uma dupla! Ou seja, duas pessoas trabalhando juntas com o mesmo objetivo em mente.
Muito óbvio, certo?
Então reflita comigo:
- Se ambas pessoas estiverem trabalhando exatamente na mesma atividade, isso configura um time?
- E se essas duas pessoas estiverem cada uma trabalhando em atividades completamente diferentes, em paralelo, elas ainda configuram um time?
- E se uma das pessoas que compõe a dupla sair do time e outra pessoa entrar no seu lugar, ainda teríamos um time?
Minha resposta seria sim para todas as perguntas. Claro, cada um dos cenários acima impõe desafios diferentes ao time, mas desde que as pessoas envolvidas estejam compartilhando um objetivo comum ou melhor, se sintam donas em conjunto pelo resultado, elas estão formando um time!
Um pouco de história…
Por muitos anos nós aqui no Itaú-Unibanco assim como muitas empresas, trabalhávamos com times de projetos de TI. Nesse antigo modelo de trabalho, as “demandas” vinham das diferentes áreas de Negócio através de um processo corporativo, eram priorizadas e times de projetos eram concebidos para implementar aquele projeto.
Esse modelo funcionava bem no passado, quando o mundo não era tão assustadoramente dinâmico como é hoje.
Aconteceu o que você já deve estar imaginando:
- Os projetos comumente tinham um escopo enorme — como a demanda era maior que a oferta (e onde não é), era difícil conseguir priorização, e uma vez o projeto priorizado, todas as features possíveis eram incluídas no escopo;
- O conhecimento técnico e funcional do sistema era fragmentado (quando não perdido), pois ao término do projeto as pessoas eram separadas e atribuídas as outro projetos com outras pessoas;
- A segurança psicológica necessária para estabelecer altos níveis de produtividade no time era difícil de ser atingida pois quando as relações entre os indivíduos se aprofundavam já era hora de tocar outro projeto;
- A arquitetura do sistema implementado era diretamente impactada, fragmentando nossas plataformas com pedaços restritos aos escopos dos diferentes projetos. Não há como fugir da Lei de Conway!
As dores e aprendizados deste modelo de trabalho foram fundamentais para implementarmos e escalarmos métodos ágeis na tecnologia, formando nossas Comunidades de Entrega. Neste novo modelo de trabalho, invertemos a lógica, criando times estáveis aonde os projetos eram atribuídos aos times.
Melhoramos muito nossa produtividade e rapidamente nos apaixonamos pelo conceito de times estáveis!
Hoje temos um modelo ainda mais maduro, nas Comunidades Integradas aos times não são mais atribuídos projetos. Eles são donos de pequenos produtos e são incentivados a atingir resultados, passando a ser responsabilidade do próprio time descobrir, implementar e manter as evoluções de seu produto.
Estabilidade! Oh Estabilidade!
Foi mágico! Mudar para um modelo de trabalho que permitisse nos conhecermos com mais profundidade, e que desse tempo para o conhecimento fluir dentro do time, foi fundamental para nossa evolução.
Acontece que caímos na cilada do movimento pendular… Saímos de um modelo de extrema instabilidade para uma mentalidade de extrema estabilidade. Em algumas situações, deixamos de tomar boas decisões e perdemos algumas oportunidades por encarar a estabilidade do time como um dogma. Venho por meio deste, desafiar esse dogma!
Times estáveis não deveriam ser times estáticos. Vamos explorar alguns dos riscos associados à estabilidade dos times:
1 — Criar novos (pequenos) silos: A última coisa que queremos depois de tanto esforço de integração para transformar nossa cultura reforçando a colaboração é criar rixas e competição entre os times. Principalmente quando se tem um codebase grande, que cruza fronteiras de diferentes times como o nosso.
2 — Represar conhecimentos: Deixar de propagar o conhecimento prático de um engenheiro ou de um designer incrível em prol da estabilidade de um time não faz sentido. A organização como um todo sai perdendo. Esse é um risco ainda maior quando falamos de complicated subsystem teams onde poucas pessoas detém um alto grau de conhecimento especializado. Se este conhecimento não for compartilhado, quando essas pessoas saírem da organização, teremos um problemão!
3 — Restringir oportunidades de desenvolvimento: Não é novidade que os melhores profissionais procuram oportunidades para se desenvolver. Criar um ambiente onde as pessoas possam ter mobilidade de papéis, atuando em produtos e escopos diferentes é uma excelente forma de reter talentos.
4 — Cristalizar a mentalidade: Como seres sociáveis que somos, estamos suscetíveis a vieses individuais e coletivos. Trabalhar sempre com as mesmas pessoas é tanto uma excelente forma de fortalecer os vínculos entre estes indivíduos como de cristalizar a maneira como estas pessoas pensam. Precisamos ser desafiados constantemente, aprender a lidar com contradições e visões opostas se quisermos ter um ambiente diverso e consequentemente catalizador de inovações. Perspectivas diferentes na construção de produtos é fundamental para inovar!
E daí?
Deve estar claro que não acredito em abordagens extremas. Um pouco de dinamicidade na composição dos times é algo bastante saudável (para além do fato de ser inevitável!).
Antes de concluir, gostaria de tecer alguns breves comentários sobre duas perspectivas diferentes: Estabilidade de Escopo v.s. Estabilidade de Composição.
Estabilidade no Escopo do Time:
O escopo, missão, propósito dos times que compõe uma Comunidade (Tribo) são definições cruciais no sucesso (ou fracasso) da Comunidade. Mudar o escopo de um time é uma decisão estratégica. Em próximas publicações vamos explorar este aspecto da Topologia: Uma ferramenta para atingir uma estratégia. Sendo assim, mudanças nos escopos dos times devem acontecer para acompanhar as mudanças e oportunidades de mercado. Inclusive, essa é uma das principais responsabilidades dos líderes de Comunidades. Sempre que os Objetivos Estratégicos mudarem, vale a pena dar uma revisada na Topologia. Dito isto, estas mudanças não acontecem semanalmente e mudanças de escopo nos times impactam diretamente os resultados da Comunidade.
Estabilidade na Composição do Time:
Mudar o Product Manager, adicionar um QA ou remover um Engenheiro de um time, são todos exemplos deste tipo de mudança. Nesse tipo de mudança é importante os gestores acompanharem o time de perto para avaliar se ele ainda tem todas as competências necessárias para gerir seu produto. É possível inclusive incentivar mudanças estratégicas na composição do time, trazendo pessoas com perfis complementares, conhecimentos especializados necessários, indivíduos com histórias de vida distintas que possam ajudar o time a mudar sua percepção sobre o impacto do produto na vida do cliente, etc. Existem algumas técnicas interessantes para intervir na estabilidade da composição de times de maneira saudável e de forma a impactar menos a produtividade. Remover diversos membros do mesmo time ao mesmo tempo, gera muito mais impacto, por exemplo, do que remover um membro, depois de alguns sprints outro e assim por diante. Heidi Helfand explora alguns padrões e melhores práticas em seu livro Dynamic Reteaming.
Conclusão
Estruturas de times de produto com escopos estáveis são uma excelente forma de inovar de maneira consistente. Estabelecer uma cultura e dinâmica de times flexíveis também! Como sempre, estarmos atentos e nos adaptando constantemente é uma estratégia superior a nos amarrarmos a métodos, processos e conceitos de maneira dogmática. O que funciona hoje, pode não funcionar amanhã.
E você, já pensou em trabalhar umas sprints na squad ao lado?
Referências
Dynamic Reteaming: The Art and Wisdom of Changing Teams
Team Topologies: Organizing Business and Technology Teams for Fast Flow
The Human Network: How Your Social Position Determines Your Power, Beliefs, and BehaviorsThe Human Network: How Your Social Position Determines Your Power, Beliefs, and Behaviors
