TLDR; Quando digo que não sou fã do modelo Feature Teams, algumas pessoas podem pensar que é consequência de falta de delegação, ou até mesmo conservadorismo organizacional. Não é nada disso. É principalmente por uma questão de eficiência que prefiro esquadrões (ou seja, equipas autónomas especializadas por tópico de negócio / Bounded Contexts) MAS combinados com a técnica Swarming sempre que necessário. Aviso: este post também contém um pequeno discurso contra a infame manobra Inverse Conway ;-)

Este artigo segue meu post anterior ( DDD é de direita? ) Que falou sobre Domain Driven Design e várias questões organizacionais. Artigo em que mencionei muito brevemente que não era fã de Feature Teams. Vou explicar aqui o porquê.

O mundo perdido das equipes de recursos

Já experimentei a moda quando todos juravam pelas equipes de recursos. Foi na década de 2010 e a maioria das grandes organizações realmente pensou que iria salvá-los de seus problemas de Cultura (), de sua dívida técnica, mas também de seu peso burocrático. O princípio é simples: formamos uma equipa centrada no cliente, multidisciplinar mas estável, à qual serão regularmente atribuídas diferentes missões. Missões diferentes, mas cada vez em torno de uma funcionalidade específica que a equipe administrará sozinha do início ao fim (corte vertical). Para conseguir isso, o Feature Team poderá intervir sozinho em todos os componentes que ficarão em seu caminho (front, back, infra, db etc).

A ideia de uma equipe de funcionalidades é que ela não precise chamar outras equipes para poder adicionar uma funcionalidade ou capacidade a um produto.

Atenção: a noção de “feature” na equipe de Feature não significa que ela seja responsável por um determinado Domínio de negócio (que seria sua especialidade). Não, a noção de “característica” corresponde antes à unidade de trabalho da equipa (que pode mudar regularmente). Uma equipe de destaque é um pouco como o A-Team: uma equipe autônoma que resolve os problemas que surgem (no início de cada episódio) e que muda constantemente de assunto antes de partir para novas aventuras.

Mas o problema surge quando…

Em tais organizações, podemos potencialmente ter várias equipes de recursos trabalhando simultaneamente em diferentes recursos, mas todos na mesma plataforma/software. Tendo visto isso aqui e ali em experiências antigas ou com clientes (quando eu era consultor), isso pode dar origem a:

• Problemas de simultaneidade entre equipes durante a codificação no mesmo componente
• Base de código heterogênea terminando com muitas abordagens de design diferentes. Portanto, levando a um código mais complicado de ler/entender/manter/evoluir (choque de culturas de desenvolvimento?)
• Projetos centrados em curto prazo, com as pessoas prestando menos atenção à durabilidade e facilidade de manutenção do código resultante. Como se fosse quase intrínseco à declaração de missão deles.

De fato, lidar com domínios complicados pode ser uma verdadeira dor de cabeça ou levar a muitos códigos de domínio anêmicos com equipes de recursos.

Então. Como enfrentar todas essas dificuldades?

O modelo de “esquadrões” do Spotify

Não é surpresa então que o modelo que surgiu nos anos seguintes foi o modelo “squads” do Spotify. Este partiu do conceito de um time multidisciplinar e estável (como um time de Feature), mas o pessoal do Spotify foi mais longe no aspecto da autonomia.

Eles pediram a cada um desses esquadrões que investissem mais tempo e permanecessem alocados em uma determinada área de negócios, um aspecto funcional específico do produto. Eles entenderam que era necessário investir um mínimo funcionalmente falando, para poder ser totalmente eficaz, autônomo e capaz de tomar decisões relevantes.

E não me interpretem mal: “Esquadrão” não é apenas um termo “legal” para falar de um time. Squads são times AUTÔNOMOS. Damos a eles uma missão que durará no tempo e pediremos que assumam a propriedade de seu domínio de negócios por conta própria.

O domínio em que uma equipe trabalha deve caber na cabeça de todos

Team Topologies (por Matthew Skelton & Manuel Pais ) surgiu alguns anos depois com o termo “Stream-aligned team”. Mas, embora eu tenha achado interessante a proposta deles de reduzir a carga cognitiva das equipes, colocando um limite superior rígido nos tamanhos das equipes (“o domínio em que uma equipe trabalha deve caber na cabeça de todos”), continuo preferindo usar o nome “Esquadrões” para representar autonomia.

Nota: trabalhar em autonomia para equipes é uma das minhas paixões, como discuti recentemente aqui em Como evitar que sua busca pela autonomia das equipes se transforme em caos…

Squads & DDD: uma dupla fantástica para lidar com a complexidade dos negócios

A autonomia é realmente o terreno comum entre o modelo “Squads” e o Domain Driven Design (DDD). De fato, este último sugere que alinhemos nosso software com as necessidades dos Domínios e dividamos nosso produto em diferentes “reinos” autônomos, mas conectados, chamados Contextos Limitados (por exemplo, Contabilidade, Vendas, Pesquisa, etc.). Estes domínios/contextos delimitados destinam-se a dar-nos mais liberdade e autonomia para entregar valor (por exemplo, não queremos necessariamente impactar e pedir opinião a equipas dedicadas ao Marketing quando mudamos uma parte da Contabilidade). Para mais detalhes sobre o que é DDD, você pode ver isto ( Domain Driven Design explicado em 3 minutos ).

Para atingir este desafio, geralmente queremos ter apenas uma equipe responsável por Bounded Context (e muitas vezes com algo como um módulo ou uma API web por BC) porque queremos que cada um deles seja consistente por dentro (em termos de design e geral abordagem).

Acima de tudo, queremos um bom momento para o mercado e equipas autónomas nas suas tomadas de decisão. Portanto, adaptamos nossa arquitetura de acordo, seguindo os limites de nosso domínio. Ter várias equipes proprietárias do mesmo Bounded Context complicaria todas as tomadas de decisão. O BTW Domain Driven Design deu um nome a uma situação em que várias equipes compartilhariam um pedaço de código: Shared Kernel .

Mesmo que tudo seja uma questão de contexto, posso dizer sem muito vergonha que um kernel compartilhado muitas vezes é uma situação dolorosa (um cheiro?) organizacionalmente falando. Exige, no mínimo, uma certa maturidade e uma cultura corporativa que valorize a colaboração dentro da empresa (coisa que você não terá se valorizar as pessoas e dar bônus individualmente, por exemplo) que são realmente raras. Não impossível, mas raro.

Resumindo: geralmente queremos evitar situações com equipes diferentes cuidando da mesma parte do negócio do nosso Produto.

O uso de equipes de recursos parece inadequado por essência em relação a este objetivo IMO.

na Agicap

Sem surpresa, foi mais ou menos isso que encontrei na Agicap quando cheguei no ano passado para ser o vice-presidente de engenharia dessa expansão europeia em expansão.

Mas, ao contrário da situação do Spotify, onde cada Squad (entenda-se “toda a equipe”) é realmente autônomo na tomada de decisões, os gerentes de produto da Agicap foram os únicos que conduziram fortemente a fase de implementação do desenvolvimento.

Funcionou muito bem até agora. Principalmente o fato de não ter Product Owners (POs), mas sim Product Managers, cobrindo tanto a fase de descoberta quanto a de entrega (muito eficiente).

No entanto, as equipes de tecnologia regularmente recebiam solicitações do pessoal do Produto para alterar a estrutura de suas equipes. Coisas como nos pedir para mover um desenvolvedor específico de uma equipe para outra para que ele se adapte melhor às suas necessidades/pressas funcionais atuais ou futuras. Seguir tais solicitações nos levaria a tomar decisões de impacto de longo prazo para as pessoas, mas com base na atualidade do produto em curto prazo (nas próximas semanas ou meses).

Qualquer que seja a perspectiva que você assuma sobre isso, não me parece uma boa ideia.

Nós não somos “recursos” pelo amor de Deus!

Meu desejo de promover equipes autônomas remonta a meados dos anos 2000, quando descobri o XP (eXtreme Programming) no trabalho. Pude experimentar o poder e a eficiência local de uma equipe XP autônoma em um projeto piloto em um grande banco de investimentos. Uma experiência incrível em tantos níveis. Muitos anos depois, também pude experimentar a frustração de trabalhar em uma grande organização que não entendia a dinâmica das equipes de desenvolvimento e do Reteaming Dinâmico . Uma organização que gastava seu tempo dividindo nossas equipes repetidamente de acordo com os projetos em voga.

Como eu disse no meu artigo anterior, leva pelo menos 6 meses para construir uma equipe de desenvolvimento eficiente, onde as relações interpessoais são efetivas e algum conhecimento de negócios é adquirido.

Gastar tempo reorganizando o casting das equipes de desenvolvimento afeta muito nossa eficiência. Além disso: não somos máquinas! Somos humanos com afetos, vínculos e apegos que tecemos ao longo do tempo com nossos colegas.

(

Pequeno parêntese: a Manobra de Conway Inversa (ICM)

Estas são as mesmas razões pelas quais alguns de nós reclamamos quando ouvimos falar da Manobra Inversa de Conway (ICM) . E não estou falando sobre a versão original do ICM que era boa (ou seja: “quebrar silos que limitam a capacidade da equipe de colaborar de forma eficaz” ). Estou falando sobre como gerações de consultores transformaram o ICM em um monstro Frankenstein (ou seja: “ mude sua organização para alcançar sua arquitetura-alvo” ).

Sobre esse tópico específico, fique atento à próxima série de ótimos artigos do meu amigo Cyrille DUPUYDAUBY (deve ser publicado em breve). Ele foi o primeiro a me alertar sobre esse assunto anos atrás e esclarecerá o porquê.

Algumas pessoas como John CUTLER ou Mathias VERRAES ( Conway's Law Doesn't Apply to Rigid Designs ), já entenderam que conceitos como a manobra inversa de Conway provavelmente eram muito ambiciosos dada a dívida funcional e técnica de certas arquiteturas:

« Finalmente, é fácil dizer “apenas capacite suas equipes!” Mesmo com as melhores intenções, isso pode não ser fácil. Sua arquitetura e estrutura organizacional atuais podem limitar suas opções. » ( John CUTLER — TBM 27/52: Níveis de Mandato )

Alguns de nós também dizem que essa manobra é antiética e ingênua pra caralho. Motivo pelo qual até falo em golpe para o ICM.

Antiético em primeiro lugar, porque não jogamos assim com pessoas, humanos reais em nossas organizações. Você não “refatora” as pessoas. Você não brinca com as pessoas como brinca com o código.

É ingênuo pra caralho também, porque a face oculta do Iceberg que você vai enfrentar é mais uma vez a Cultura. Algo familiar para entusiastas da gestão de mudanças como eu. Lembrar? Aquele que come todas as estratégias no café da manhã (cf. Peter Drucker).

)

Feito esse parêntese do lado humano, vamos voltar ao nosso assunto principal: o que o Swarming pode trazer para times estáveis ​​e autônomos (ou seja, Squad).

Swarming: aquele pequeno extra que precisávamos para uma organização DDD eficiente

Bem. Primeiro: vamos explicar o que é Swarming. Swarming é como uma Força-Tarefa (portanto temporária), mas dentro da qual teremos definido desde o início quem será o responsável pelo suporte à produção de qualquer software resultante (ponto ainda mais importante se, como nós, você estiver em um “você constrói isso, você executa!” modo). Ele esclarece muitas decisões de design coletivo e evita a conhecida situação ao encerrar uma força-tarefa: “A propósito: quem cuida do suporte para essa coisa que acabamos de fazer juntos?!?” (longo silêncio ;-) Quanto a uma força-tarefa, os membros de um Swarming vêm de várias equipes diferentes e terão que trabalhar juntos para resolver um problema de curto prazo (antes de voltar para seu esquadrão no final do dia)

Além de sua eficácia em conseguir as pessoas certas para colaborar dependendo do assunto, uma iniciativa de Swarming traz muito capital social para uma organização ao promover temporariamente o relacionamento interpessoal entre diferentes squads (super útil para o futuro quando todos retornarem ao seu squad).

Por que precisamos do Swarming?

Se forçarmos demais e entendermos mal o conceito de autonomia recomendado pelo DDD, podemos ser tentados a confundir autonomia com isolamento. Também podemos ser tentados a nos isolar um pouco demais… Para ver cada conectividade e cada interação entre os BCs como o mal absoluto a ser evitado.

Já vi muitas pessoas caindo na armadilha de parar de pensar nos outros e focar apenas em seus próprios Contextos Delimitados, em sua própria equipe. Pode ser fácil esquecer que fazemos parte de um ecossistema onde cada parte tem um papel a desempenhar e onde as interações devem ser limitadas -claro- (em termos de superfície de exposição), mas não ignoradas. Nosso trabalho deve ser útil e usado. Todos (PMs, desenvolvedores) sonham com uma situação em que nunca precisemos de outras equipes/BCs para avançar e agregar valor. Mas todos sonham...

Qualquer maneira. Nada disso bate com o que o DDD nos diz. Em vez disso, o DDD deseja que cada Bounded Context seja o mais autônomo, é claro, mas ainda assim útil para as necessidades de nossos usuários. Para conseguir isso, precisamos conectar sabiamente os diferentes BCs, não escondê-los totalmente uns dos outros. E é para isso que serve a maioria dos padrões estratégicos do DDD: para nos ajudar a permitir com segurança essas interações entre os BCs.

Pois bem, o Swarming intervém justamente nesses poucos casos em que precisamos trabalhar na sincronização e interação entre 2 ou mais Bounded Contexts.

O enxame também pode nos ajudar a sobreviver a situações em que nossos BCs ainda não estão bem definidos. Antes de um esclarecimento de Domínio ou Mapa de Contexto.

Quando um Swarming termina, todos encontram sua equipe e seus súditos. Swarming é apenas uma maneira muito eficiente de colaborar com pessoas de várias equipes e especialistas de domínio para atingir um objetivo de maneira eficiente.

É por isso que quis experimentar esta técnica quando cheguei, há um ano. E devo admitir que nunca me canso de ver os efeitos benéficos dela (agora que já faz alguns meses que não a experimentamos aqui ou ali).

Para concluir: Swarming FTW!

Como mencionei no início deste artigo, tenho visto tantas situações complicadas, mas acima de tudo bases de código inconsistentes depois de terem sido tocadas por várias equipes de recursos que não acho que o Feature Team seja mais interessante.

Pior, já vi muitas vezes equipes de recursos não muito conhecedoras nem interessadas nas sutilezas ou na linguagem onipresente de cada parte funcional / BC. Todas as vezes, o impacto na base de código foi dramático (domínio anêmico ou aproximado).

Razão pela qual não acho que as equipes de recursos possam competir com os esquadrões combinados com Swarming sempre que precisarmos nos esforçar muito em um determinado tópico ou colaboração.

Próximos passos

Hoje, na Agicap, o pessoal da tecnologia está muito próximo de seus gerentes de produto. Mas a próxima etapa de nossa jornada de melhoria contínua será que os gerentes de produto envolvam ainda mais cedo o pessoal da tecnologia durante sua descoberta (o famoso “shift-left” para tecnologia).

Eu também gostaria que começássemos a considerar as trilhas duplas de Descoberta Contínua / Entrega Contínua, tão caras a Marty Cagan e Jeff Patton. Isso deve nos permitir ainda mais colocar nossa força de energia e engenharia APENAS em ideias validadas por nossos clientes. Melhorar ainda mais a relação custo/benefício de nossas ações.

« Maximize o valor, minimize o esforço » (Jeff Patton)

Mas isso será assunto de postagens futuras, eu acho.

Para saber mais sobre a Agicap:

• Mostre-me seu domínio ( monitoramento de fluxo de caixa e sessão de mapa de contexto de previsão )
• https://agicap.com/
• https://career.agicap.com/