Estruturas de times e suas interações
Reflexões a partir do livro Team Topologies
Tive meu primeiro contato com o livro no final de 2020, em um evento do grupo Tech Leadership BR, na ocasião, Eduardo Matos apresentou um overview baseado no livro e logo depois organizou outro encontro com o próprio Manuel Pais — coautor — sobre interações entre equipes no contexto do trabalho remoto.
Nos encontros, alguns assuntos me chamaram a atenção por irem além da discussão mais comum e, muitas vezes, apaixonada sobre os formatos de times (squads, guildas, chapters) e metodologias/frameworks utilizados por eles (kanban, scrum, XP, SAFe). Tocaram também em pontos interessantes e necessários para auxiliar na estruturação de grandes equipes como: dependências, colaboração e comunicação entre times, carga cognitiva, lei de Conway, número de Dunbar, times de plataforma, APIs de times, entre outros.
Peguei uma boa promoção na Amazon para versão digital do livro e vou destacar nesse post os principais insights que tive durante minha leitura.
O livro e os autores
Team Topologies: Organizing Business and Technology Teams for Fast Flow foi lançado em 2019, pela editora IT Revolution, responsável por algumas obras consideradas referências nos assuntos DevOps e gestão de empresas/produtos modernos, como: Accelerate, DevOps Handbook, The Phoenix Project, Making Work Visible e vários outros.
Os autores Matthew Skelton e Manuel Pais são especializados no mundo DevOps, ajudam empresas com consultoria e treinamentos, além de disseminarem ótimos conteúdos sobre o tema, como esse post de 2013: What team structure is right for devops to flourish?.
Lei de Conway
O livro é repleto de referências bibliográficas que enriquecem a estrutura conceitual do conteúdo, a lei de Conway é uma das mais citadas pelos autores e é base para algumas definições dos padrões e abordagens da obra.
Qualquer empresa que projeta um sistema, inevitavelmente, produz um projeto cuja a estrutura é uma cópia da estrutura de comunicação da organização.
Citação feita em 1968 por Melvin Edward Conway, um cientista da computação, que cunhou o que agora é conhecido como a lei de Conway.
De forma resumida, podemos dizer que o design organizacional prevalece sobre o design da arquitetura de software.
Evidências em apoio à lei de Conway foram publicadas por uma equipe de pesquisadores do Massachusetts Institute of Technology (MIT) e da Harvard Business School, os autores destacam o impacto das decisões de design organizacional na estrutura técnica dos artefatos que essas organizações desenvolvem posteriormente.
Um ponto interessante é que outras disciplinas, como UX , também percebem esse tipo de comportamento:
As organizações geralmente produzem sites com conteúdo e estrutura que refletem as preocupações internas da organização, ao invés das necessidades dos usuários do site. Nigel Bevan — 1997
Arquitetura de software e o design organizacional
Como vimos anteriormente, com o tempo a estrutura de um software tenderá a replicar a estrutura de comunicação da empresa que o desenvolve.
As imagens abaixo demonstram dois tipos diferentes de estruturas de times que facilmente se confundem com os próprios desenhos das soluções entregues por eles.
Se a intenção é não ter uma base de dados monolítica, então é essencial diluir o “núcleo DBA” nas squads. Se a intenção é permitir deploy independente é importante entender que o “núcleo de operações” também precisa ser diluído. Se for oferecer uma experiência consolidada, é imprescindível considerar uma equipe responsável por isso (UX nesse exemplo).
Quando estudamos arquitetura de software, temos algumas boas práticas conhecidas:
- Baixo acoplamento: os componentes não possuem fortes dependências de outros componentes;
- Alta coesão: os componentes têm responsabilidades claramente delimitadas e seus elementos internos estão fortemente relacionados;
- Compatibilidade de versão clara e apropriada;
- Testes entre equipes claros e apropriados.
Tendo consciência sobre a lei de Conway e as boas práticas de arquitetura de software, podemos aplicá-los no desenho dos times considerando essas premissas. Isso é conhecido como manobra reversa de Conway e pode ajudar a evitar uma incompatibilidade entre a arquitetura da empresa e a arquitetura desejada do software.
Independent Service Heuristics: com base em técnicas como o Domain Driven Design (DDD), os autores disponibilizam um guia para ajudar a identificar jornadas, domínios, serviços, aplicativos ou tarefas que poderiam ser isoladas e tratadas em um produto/serviço separado.
Dores da abordagem tradicional
Historicamente, a maioria das organizações viu o desenvolvimento de software como um tipo de manufatura a ser concluído por indivíduos separados e organizados em especialidades funcionais, comprometidos em grandes projetos planejados antecipadamente, e com pouca consideração para a dinâmica sociotécnica. Isso levou aos obstáculos citados na imagem acima.
Desenvolver e operar software moderno de maneira eficaz exige que as organizações considerem muitas dimensões diferentes. Os movimentos Agile, Lean e DevOps ajudaram a mostrar o valor de equipes menores e mais autônomas, alinhadas ao fluxo de negócios, desenvolvendo e lançando em pequenos ciclos iterativos, corrigindo o curso com base no feedback dos usuários.
No entanto, organizações tradicionais, costumam ser limitadas em sua capacidade de colher plenamente os benefícios desses movimentos devido aos modelos organizacionais defasados. Normalmente, o foco é na automação mais imediata e na adoção de ferramentas/frameworks, enquanto as mudanças culturais e organizacionais acabam não sendo priorizadas.
Indivíduos e interações mais que processos e ferramentas.
Team Topologies descreve como ter a estrutura e interações adequadas de equipes, entendendo a necessidade de evoluir ao longo do tempo para que possamos projetar os times de forma consciente. Além disso, a abordagem dos autores permite que a organização se adapte e encontre, dinamicamente, os locais e os momentos em que a colaboração é necessária, bem como quando é melhor se concentrar na execução e reduzir a sobrecarga de comunicação.
Os 4 tipos fundamentais de times
- Stream-aligned team: alinhado a um fluxo de trabalho que, geralmente, é do domínio de negócios. Esse é o tipo mais importante, os outros três existem para facilitar a vida do stream-aligned (time de produto);
- Enabling team: ajuda um stream-aligned team a superar obstáculos, também detecta disciplinas ausentes. O modelo de equipe atua como consultores especializados e sob demanda para os times de produto (acessibilidade, dados, BI, QA, cloud, entre outros);
- Complicated subsystem team: onde matemática/cálculo/conhecimentos técnicos significativos são necessários. O time foca em uma parte muito técnica e específica, por exemplo, criar um componente para processamento de vídeo, OCR, reconhecimento facial, etc;
- Platform team: um agrupamento de outros tipos de equipe que fornecem um produto interno atraente para acelerar as entregas do stream-aligned team. A equipe foca em fornecer uma plataforma que abstrai complexidade (de infra, por exemplo) para ser consumida como autosserviço. Dessa forma, o time de produto se concentra na entrega de valor para o cliente.
Em uma grande e tradicional empresa, podemos ter vários times com disfunções herdadas de modelos anteriores, tentar categorizar e organizar nesses quatro principais tipos, facilita rever o propósito, dependências, perfis e prioridades. Com isso, conseguimos equilibrar as equipes de acordo com as necessidades atuais de negócios, clientes e do próprio software.
3 tipos de interações entre times
Interações bem definidas é a chave para equipes eficientes
- Colaboração: trabalham juntos, por um período de tempo definido, para descobrir coisas novas como APIs, práticas, tecnologias e outros;
- X-as-a-Service: uma equipe fornece algo e outras equipes consomem “as a service”;
- Facilitação: uma equipe ajuda e orienta outra equipe.
Definir, explicitamente, os limites de cada equipe, as dependências e a maneira que os times interagem, ajuda a melhorar o fluxo de entrega de valor.
Este diagrama não é estático, os relacionamentos das equipe irão mudar à medida que novas metas forem definidas e as equipes descobrirem coisas novas.
O número de Dunbar
Define o limite cognitivo teórico do número de pessoas, com as quais um indivíduo pode manter relações sociais estáveis. Esse número teórico varia entre 100 e 230 pessoas e tem sido constantemente citado em pesquisas da antropologia. Deve-se notar que o tamanho de pequenas comunidades — tribos, aldeias, grupos de interesse comum — costuma se manter nessa faixa.
Alguns dos mais famosos usos do número 150 derivam-se de observações empíricas feitas em estruturas sociais variadas: política, performance no trabalho, organizações militares e redes sociais.
Número de Dunbar ≅ 150
Tamanhos de times
We try to create teams that are no larger than can be fed by two pizzas.
We call that the two-pizza team rule.
Jeff Bezos
Com base no número de Dunbar, os autores sugerem alguns limites para os tamanhos das equipes:
- Cerca de 5 pessoas: limite de pessoas com quem podemos manter relacionamentos pessoais íntimos;
- Cerca de 15 pessoas: limite de pessoas com quem podemos ter uma confiança profunda;
- Cerca de 50 pessoas: limite de pessoas com quem podemos ter confiança mútua;
- Cerca de 150 pessoas: limite de pessoas cujas capacidades podemos lembrar.
A dinâmica da confiança pode mudar ao cruzar o limite de Dunbar, então, se prepare para regras diferentes e efeitos não lineares.
Além do tamanho, é importante mencionar sobre a boa prática de tentar manter a equipe estável durante um período (algo entre 9–12 meses), pois leva tempo para um time ficar entrosado e eficaz.
Carga cognitiva
Esforço cognitivo ou carga cognitiva se refere ao nível de utilização de recursos psicológicos como memória, atenção, percepção, representação de conhecimento, raciocínio e criatividade na resolução de problemas.
Um dos fatores menos reconhecidos que aumentam o atrito na entrega de software moderno é o tamanho e a complexidade, cada vez maiores, das bases de código que as equipes precisam trabalhar. Isso cria uma carga cognitiva ilimitada nas equipes.
O estudo sobre carga cognitiva e as implicações para a engenharia pedagógica, definiu três tipos:
- Carga cognitiva intrínseca — relaciona-se a aspectos da tarefa, fundamentais, para o espaço do problema, por exemplo: “qual é a estrutura de uma classe Java?”, “como faço para criar um novo método?”;
- Carga cognitiva externa — relacionada ao ambiente, no qual a tarefa está sendo realizada: “como faço para implantar este componente novamente?”, “como faço para configurar este serviço?”;
- Carga cognitiva apropriada — relaciona-se a aspectos da tarefa que precisam de atenção especial para aprendizagem ou alto desempenho: “como este serviço deve interagir com o serviço ABC?”.
Quando os times não possuem o tamanho adequado ou a estrutura pertinente, com frequente troca de contexto, a carga cognitiva aumenta e atrapalha o fluxo de entrega de valor. Essa parte do livro me remeteu aos mantras do Kanban como a limitação do WIP e o “pare de começar e comece a terminar”.
Tendo consciência sobre a carga cognitiva, devemos gerenciar a carga intrínseca, otimizar a carga externa e promover a carga apropriada.
Uma maneira simples e rápida de avaliar a carga cognitiva do time é perguntar à equipe, sem fazer julgamentos: “você se sente eficaz e capaz de responder em tempo hábil ao trabalho que lhe é solicitado?”
Os autores fornecem um modelo para avaliação de carga cognitiva da equipe o Team Cognitive Load Assessment.
Team APIs
Para demonstrar clareza do propósito das equipes e explicitar o melhor formato e local de comunicação, pode ser útil definir uma “API de equipe” para cada time. Eles fornecem um template interessante no GitHub:
*Para times de plataforma, os autores sugerem um template de wiki que fornece informações sobre os serviços, documentações, tempos de respostas por tipo de contato, roadmaps e canais de comunicação.
Rastreamento de dependências
Todas as equipes fazem parte de um sistema sociotécnico e, portanto, dependerão de outras equipes em algum momento, em maior ou menor grau.
Isso significa que devemos rastrear dependências entre as equipes agora e ao longo do tempo. Algumas dependências podem funcionar hoje, mas, em alguns meses, elas começarão a desacelerar muito a equipe dependente e precisamos resolver isso.
Embora, idealmente, possamos querer remover todas as dependências, na prática devemos identificar quais são problemáticas e devem ser removidas e quais estão “sob controle”, pelo menos por enquanto. Uma dependência problemática introduz atrasos significativos e são muito imprevisíveis, aumentam o trabalho em andamento (WIP) para a equipe dependente, tornando-os consideravelmente mais lentos.
Como um exemplo de aplicação, durante um período, o Spotify rastreou as dependências entre equipes com uma simples planilha:
Take away
Precisamos tirar proveito da lei de Conway (o design organizacional prevalece sobre o design de arquitetura de software), levar em consideração as restrições de carga cognitiva para projetar equipes com objetivos claros, promover interações entre equipes que priorizam o fluxo de entrega de software e criar um ambiente que facilite aplicar estratégias de adaptabilidade.
Algumas ações práticas:
- Mapear as dependências entre times;
- Definir as fronteiras dos times;
- Promover interações com propósito;
- Estimular feedback constante e construtivo.
Agradeço a leitura até aqui e estou aberto para feedbacks e troca de experiências sobre o tema.
Para finalizar, recomendo a leitura e consulta aos materiais extras no site e github do livro:
