Entrevista sobre o livro Team Topologies

O livro Team Topologies, escrito pelo Matthew Skelton e Manuel Pais, mostra como organizar equipes dentro de uma empresa a fim de permitir a entrega eficaz de softwares, descrevendo quatro tipos fundamentais de equipe, três padrões de interação, além de mergulhar nos limites de responsabilidade das equipes e como elas podem se comunicar ou interagir com outros times. O livro também explica por que e como as empresas precisam ouvir os sinais internos e externos para saber quando evoluir as estruturas de equipe para atender às novas demandas.

Os leitores do InfoQ podem fazer o download do primeiro capítulo do livro, clicando aqui.

O InfoQ entrevistou Matthew Skelton e Manuel Pais abordando os obstáculos do fluxo rápido das empresas, a manobra reversa de Conway, como incentivar os membros da equipe a desenvolver uma mentalidade de grupo, as quatro topologias fundamentais, e solicitou alguns conselhos em relação a arquitetos e equipes de arquitetura.

InfoQ: Por que decidiram escrever o livro?

Matthew Skelton: Ajudamos muitas empresas em todo o mundo a entender e melhorar o design e a dinâmica organizacional de entrega de software e queríamos compartilhar algumas das ideias que desenvolvemos. Vimos pessoas e equipes em inúmeras empresas lutando para entender como e por que deveriam interagir com outras pessoas e equipes, levando à frustração e ineficácia. Ao escrever o livro Team Topologies, esperamos ajudar as pessoas a obter clareza e propósito.

Manuel Pais: Desde que as topologias originais do DevOps foram publicadas em 2013, milhares de empresas em todo o mundo as utilizam e as consideraram úteis. Sabemos que empresas como a Netflix usaram os padrões para ajudar a desenvolver suas equipes, também os utilizaram a Condé Nast International, Accenture e Adidas. Percebemos que com os padrões de topologias fornecemos algo muito útil para o setor de TI, mas queríamos ir além das estruturas estáticas de equipe apresentadas nos padrões de topologias originais para incluir dimensões como a Lei de Conway, carga cognitiva da equipe, modos de interação e percepção organizacional para a evolução do time. O resultado é este livro.

InfoQ: Para quem se destina?

Pais / Skelton: Escrevemos o livro Team Topologies para qualquer pessoa envolvida na construção e execução de sistemas de software modernos. No livro existem padrões úteis para engenheiros, testadores, SREs e Ops, especialmente em relação às interações e comportamentos dentro da equipe. Existem informações importantes para arquitetos e chefes de departamento, responsáveis por pensar sobre os limites de responsabilidade nos sistemas. Há ainda conceitos e temas cruciais para os executivos, porque o design da empresa é efetivamente uma restrição no "espaço de pesquisa da solução" e, portanto, para um determinado design da empresa, algumas soluções nunca serão descobertas. Essa é uma preocupação estratégica para o C-level.

Tentamos escrever o livro de uma maneira que seja acessível a todos, com jargões limitados e exemplos claros. Várias pessoas nos disseram que tivemos sucesso quanto a isso, o que nos deixou muito contentes.

InfoQ: O que são topologias de equipe?

Skelton: As topologias de equipes descrevem como estas são organizadas em uma empresa, incluindo os limites de responsabilidade e como se comunicam ou interagem umas com as outras. O pensamento do livro Team Topologies remonta a 2013 quando usei a expressão pela primeira vez para descrever alguns padrões de equipe que pareciam funcionar no contexto do DevOps. Desde então, nós, juntamente com o envolvimento da comunidade, selecionamos os padrões conhecidos das topologias do DevOps, que ajudaram muitas empresas em todo o mundo a pensar e otimizar as equipes para a entrega de software.

Pais: No livro Team Topologies, expandimos muito o pensamento e os padrões para que equipes sejam bem-sucedidas na entrega de softwares. Definimos quatro tipos principais de equipes (que discutiremos ainda neste artigo), três modos principais de interação da equipe (colaboração, tudo como serviço e facilitação), juntamente com muitos outros padrões e heurísticas para o design eficaz da empresa. No final, a entrega bem-sucedida de software não é apenas sobre como estruturamos as equipes, mas também como elas interagem, como antecipamos a Lei de Conway, dimensionamos corretamente as responsabilidades do software e configuramos a empresa para aprender e evoluir.

InfoQ: Quais obstáculos ao fluxo rápido podem ser vistos nas empresas?

Pais / Skelton: Um grande obstáculo ao fluxo rápido de mudanças em muitas empresas é a presença de silos funcionais, que são grupos de pessoas com habilidades semelhantes, cuja contribuição é necessária para que a mudança ocorra. O problema dos silos é que as transferências entre grupos agem como enormes bloqueadores do fluxo.

O que descrevemos no livro Team Topologies, e o que as empresas com visão de futuro estão fazendo, é ter a maioria dos colaboradores trabalhando em equipes multifuncionais alinhadas ao fluxo de mudanças, o que chamamos de equipes alinhadas ao fluxo. Esses grupos são responsáveis de ponta a ponta pela implementação de uma alteração ou parte de uma nova funcionalidade, incluindo o suporte ao novo software na produção.

Ao remover as transferências e silos, podemos configurar a empresa para um fluxo rápido de mudanças alinhadas às áreas relevantes para os negócios. Obviamente, isso não acontece automaticamente. Abordamos alguns outros requisitos no livro.

InfoQ: Como funciona a manobra reversa de Conway?

Pais / Skelton: A manobra reversa de Conway (ou Conway inverso) é uma abordagem para otimização da empresa, popularizada por pessoas como James Lewis da ThoughtWorks e Tobbe Gyllebring, que busca combinar a estrutura de comunicação da empresa com a arquitetura de software real ou desejada, construída pela entidade. Dessa forma, a empresa não está mais lutando contra a força de espelhamento homomórfica (auto-semelhante) da Lei de Conway. Como diz a especialista em software Ruth Malan, "As divisões organizacionais vão impulsionar as verdadeiras costuras do sistema".

Uma empresa que emprega a abordagem reversa de Conway determina primeiro a arquitetura de software mais eficaz para o fluxo rápido, provavelmente baseada em contextos separados de negócios e provavelmente usando uma arquitetura baseada em pequenos serviços de software. Em seguida, a empresa começa a estruturar as pessoas em equipes cujos caminhos de comunicação correspondem à arquitetura de software pretendida, idealmente um serviço ou um domínio de negócios por vez, mas, normalmente, de maneira mais imediata.

A manobra reversa de Conway não garante a entrega efetiva do software, mas resulta em mais tempo e esforço gastos no cumprimento das metas de negócios, do que no combate às incompatibilidades de comunicação entre empresa e software.

InfoQ: Como podemos incentivar os membros da equipe a desenvolver uma mentalidade de pensamento focado no grupo?

Manuel Pais e Matthew Skelton: É surpreendente quantas empresas afirmam ter equipes, mas na verdade possuem apenas grupos de pessoas com o mesmo gerente. Atualmente, temos muitas técnicas para ajudar as pessoas a trabalharem em equipe:

• Programação em pares - que ajuda a desenvolver o trabalho em dupla;
• Programação em mob - que ajuda a desenvolver abordagens de toda a equipe em relação aos problemas;
• Limites de Kanban e WIP - que ajuda as pessoas a se concentrarem na entrega de toda a equipe;
• Estatutos da equipe - que ajuda as pessoas a adquirir o hábito de se comportar de maneiras que beneficiem a equipe como um todo;
• Coaching - que ajuda as pessoas a adotar e reforçar comportamentos recém-aprendidos para momentos como retrospectivas e discussões.

Alguns comportamentos em nível de equipe precisam ser incentivados pelo departamento de Recursos Humanos (RH). Por exemplo, em vez de atribuir um orçamento anual de treinamento para cada indivíduo, atribua um orçamento de treinamento para toda a equipe. Dessa forma, se um membro da equipe for particularmente bom em participar de conferências e apresentar relatórios, a equipe poderá optar por enviar essa pessoa várias vezes, haja vista que o grupo como um todo irá se beneficiar.

No livro Team Topologies, também caracterizamos alguns padrões de comportamento de equipe adequados para diferentes tipos de equipes. Fizemos isso porque descobrimos em nosso trabalho de consultoria que muitas pessoas simplesmente não tinham a experiência ou o contexto para saber como a equipe deveria interagir com as demais. Os padrões no livro fornecem alguns modelos para uma mentalidade de equipe em primeiro lugar.

InfoQ: Como são as quatro topologias fundamentais da equipe?

Pais / Skelton: Os quatro tipos fundamentais de equipe são, em nossa opinião, os únicos tipos necessários para a entrega moderna de software otimizada para fluxo rápido:

• Equipe alinhada ao fluxo: equipe multifuncional responsável por um fluxo de alterações geralmente alinhadas a parte do domínio de negócios. A essa equipe pertencem a entrega e a execução de ponta a ponta do serviço dos softwares que criam;
• Equipe capacitadora: uma equipe que permite que as demais que estão alinhadas ao fluxo aumentem a capacidade por um período de tempo ou se familiarizem com uma nova tecnologia ou abordagem;
• Equipe de subsistema complicado: uma equipe opcional de especialistas qualificados, onde as habilidades são muito difíceis de serem colocadas em equipes alinhadas ao fluxo;
• Equipe de plataforma: Responsável por criar e executar uma plataforma atraente que acelera e simplifica a entrega de software para equipes alinhadas pelo fluxo. A plataforma é um grupo em si, provavelmente composto por equipes internas alinhadas ao fluxo e uma plataforma de nível inferior. Um fractal!

De fato, apenas a equipe alinhada ao fluxo é realmente necessária, os outros tipos de equipe dão suporte efetivo às equipes alinhadas ao fluxo. Na prática, em grandes empresas, veremos todos os quatro tipos de equipe trabalhando juntas.

Um ponto importante é que elas devem ter vida longa, não serem criadas e dissolvidas após apenas algumas semanas. O verdadeiro desempenho da equipe excede em muito o desempenho de grupos de indivíduos, mas leva tempo para que a dinâmica da equipe se torne ideal. Geralmente várias semanas ou meses.

InfoQ: Qual o conselho quanto aos arquitetos e as equipes de arquitetura?

Pais / Skelton: Felizmente, os dias de equipes de arquitetos de software e arquitetos de sistemas trabalhando separadas, já devem ter ficado para trás. A ideia de projetar um sistema de software à parte do feedback diário recebido pelas equipes parece anacrônica. No entanto, ainda existem papéis importantes para pessoas com a visão ampla e aptidão de um arquiteto:

1. No nível da equipe, os arquitetos experientes podem fazer parte dos times de capacitação para ajudar as demais equipes alinhadas ao fluxo a aumentarem o conhecimento da arquitetura e abordarem a operacionalidade, a testabilidade e assim por diante. Nesta função, os arquitetos também fornecerão informações às equipes de plataforma, pois detectarão lacunas nos recursos das equipes de fluxo e dentro da plataforma, portanto, estão idealmente posicionados para ajudar a preencher essas lacunas.
2. No nível corporativo, os arquitetos podem ajudar a moldar as interações da equipe e o design da empresa de maneira que leve em consideração a Lei de Conway e, portanto, evitando uma incompatibilidade entre a comunicação da empresa e a arquitetura de software pretendida.

Ao entender as implicações da lei de Conway, perceberemos que qualquer pessoa que tenha influência sobre o design da empresa também está atuando como arquiteto de software. Desejamos que colaboradores da área de recursos humanos ou gerentes projetem a arquitetura de software por acidente? Provavelmente não! Portanto, os arquitetos têm um papel crucial a desempenhar se abordarem não apenas a arquitetura técnica, mas também a arquitetura humana e social.

Sobre os autores

Matthew Skelton é co-autor do livro Team Topologies: organizing business and technology teams for fast flow. Chefe de consultoria da Conflux (confluxdigital.net), é especialista em dinâmicas contínuas de entrega, operacionalidade e empresas de software em fabricação, comércio eletrônico e serviços online, incluindo nuvem, IoT e software incorporado. Possui diplomas universitários em Ciência da Computação e Cibernética, Neurociência e Música, e é Engenheiro Chartered (CEng). Skelton pode ser encontrado no Twitter e no Linkedin.

Manuel Pais é um DevOps, coach e consultor de entregas, focado em equipes e com foco no fluxo. Ajuda as empresas a adotar a automação de testes e a entrega contínua, além de entender o DevOps sob perspectivas técnicas e humanas. Pais atua no setor desde 2000, tendo trabalhado na Bélgica, Portugal, Espanha e Reino Unido. Pais é o coautor do Team Guide to Software Releasability (2018), é bacharel em Ciência da Computação pelo Instituto Superior Técnico e mestre em engenharia de software pela Universidade Carnegie Mellon, podendo ser encontrado no Twitter e no Linkedin..