Organização ágil da equipe: Squads, Chapters, Tribes and Guilds

Há uma tendência crescente em torno da reorganização ágil da organização da empresa com a Agile e a Scrum.

Por que reorganizar?

Obviamente construir um produto que seja flexível, de alta qualidade e que possa reagir rapidamente à demanda do mercado é importante, mas para mim ter um processo e organização que emula isso é tão importante quanto. “Não apenas conserte o produto, conserte o processo também”

Se olharmos para exemplos da vida real de empresas que falharam, que lidam com tecnologia herdadas e aqueles que abraçam a mudança e inovam — a imagem fala volumes:

Uma dasrazões é a escalabilidade, à medida que sua empresa cresce, você precisa estar em posição de expandir e crescer de forma fácil e indolor. Especialmente em empresas menores.

Por exemplo, quando você tem uma pequena startup, geralmente os papéis são bastante vagos e as pessoas geralmente fazem o que é preciso para fazer as coisas. Isso é bom nos primeiros dias porque você precisa se mover rápido e entregar, mas à medida que você cresce este não é um modelo sustentável.

Você vai descobrir que vai começar a haver conflito, pessoas pisando uns nos outros, o que só é resolvido normalmente atribuindo papéis e responsabilidade. Scrum promove que você tenha equipes de recursos, equipes totalmente autônomas que têm responsabilidade completa pelo que eles constroem:

Muitas empresas utilizam isso; O Spotify é o mais famoso no momento e atualmente é o garoto-propaganda do Agile, e mesmo na minha própria experiência esta é uma das maneiras mais ideais de gerenciar o desenvolvimento de produtos. O Spotify também renomeia suas equipes de desenvolvimento de ‘Squads’ o que é uma ideia legal para superar o estigma de que uma Equipe de Desenvolvimento deve conter apenas desenvolvedores. Eu olhei para outras empresas que adotaram esta convenção de nomeação, e algumas que até chegaram a sua própria, como:

  • Crew
  • Party
  • Unit
  • Faction
  • Troop
  • Lineup

Embora renomear sua equipe não mude automaticamente tudo e torne sua equipe instantaneamente mais eficaz, se você estiver fazendo algumas mudanças organizacionais, reestruturando ou adaptando scrum da cachoeira — é uma boa maneira de se desvincular da maneira antiga de fazer as coisas e pode fazer a mudança mais de um impacto.

O Spotify também introduz os termos ‘Tribos’, ‘Capítulos’ e ‘Guildas’, que eu experimentei (não com a convenção de nomeação), mas os objetivos dessas equipes são uma ótima maneira de promover o trabalho em equipe, a colaboração e a inovação, além de dar aos membros da equipe propriedade e uma sensação de capacitação.

Dimensionamento no Spotify

Veja abaixo o exemplo do Spotify:

Para explicar, o Spotify divide suas equipes em equipes muito pequenas, que possuem uma determinada parte da funcionalidade de ponta a ponta, por exemplo, a pesquisa ou artistas recomendados. Um esquadrão (equipe scrum) terá um proprietário de produto dedicado que irá alimentá-los histórias de usuários para construir. Este é o padrão criado para qualquer organização que faça scrum. Esses esquadrões sentam-se juntos e têm uma missão de longo prazo. Eles têm todas as habilidades e ferramentas necessárias para projetar, desenvolver, testar e liberar para a produção, sendo uma equipe autônoma e auto-organizadora que são especialistas em sua área de produtos. Eles são como mini startups.

Como eu disse, o Spotify é bastante granular com suas equipes, então esses esquadrões são agrupados no que eles chamam de ‘Tribos’. Estes são uma coleção de esquadrões dentro da mesma área de negócio, por exemplo, eles poderiam ser uma tribo focada em dispositivos móveis. Os esquadrões dentro de uma tribo se sentam na mesma área, e geralmente há 100 ou menos por tribo. O Spotify implementa coisas como lounges compartilhados para criar interação entre squads e eventos regulares de equipe informal e se reunir onde os squads compartilham o que estão trabalhando. Há um papel de Líder da Tribo que é responsável por fornecer o ambiente certo para todos os esquadrões.

Os capítulos são outra forma de o Spotify promover a colaboração e a inovação da equipe. Os capítulos são um grupo ou membros da equipe que trabalham dentro de uma área especial. Assim, por exemplo, um esquadrão pode ser composto por desenvolvedores de escritórios frontais, desenvolvedores de back office, administrador de banco de dados e testadores. Assim, um capítulo pode ser um “capítulo de front office”, onde os desenvolvedores de escritórios se reúnem e trocam ideias, recebem ajuda em desafios e discutem novas tecnologias. Por exemplo, um desenvolvedor pode começar a usar o AngularJS em um novo recurso, e irá retransmitir para o resto do capítulo sua experiência e discutir sobre como outros esquadrões podem usá-lo. Esta é uma ótima maneira de promover a inovação e a “polinização cruzada” de ideias entre as equipes. Há um papel de Chapter Lead que é o gerente de linha para membros do capítulo, eles são responsáveis por desenvolver pessoas e definir salários, mas eles permanecem parte de um esquadrão e ainda fazem o trabalho diário.

Finalmente, há o conceito de uma guilda. Uma guilda é uma comunidade de membros com interesses compartilhados. Trata-se de um grupo de pessoas em toda a organização que querem compartilhar conhecimento, código de ferramentas e práticas. Cada guilda tem um co-coordenador, e tais guildas incluem: web technology guild, guilda de automação de testes ou até mesmo uma guilda de coaching ágil. Também pode haver guildas em coisas como fotografia, design ou qualquer outro interesse comum.

Como você pode implementar em sua equipe?

Este conceito funciona bem se você tem uma organização bastante grande, e você tem equipes de scrum maduras. O Spotify nasceu uma empresa ágil, então a maioria dessas coisas são costuradas em seu DNA, mas para empresas ou equipes em transição para scrum pode ser muito mais difícil, esse conceito precisa de um não de compra e motivação da equipe.

Embora você possa não ser capaz de implementar este modelo, existem algumas coisas que você pode tirar dele:

Renomeando seus ‘Times’/Esquadrões

Como eu disse antes, se você quiser remover o estigma de ‘Equipes de Desenvolvimento’ que contêm apenas desenvolvedores, você pode renomear sua equipe para uma das sugestões anteriormente no post. Eu gosto da ideia de uma equipe; me lembra a tripulação em um navio — cada um tem seu papel de garantir que o navio permaneça no caminho certo para o seu destino; É uma boa metáfora para usar.

No entanto, sua equipe deve representar isso, eles precisam ser uma equipe totalmente autônoma, transe com funcionalidades que tem responsabilidades completas e pouca ou nenhuma dependência dos outros. O ideal é que as equipes fiquem em torno de 5 a 7 pessoas de tamanho. Isso garante que eles possam ser facilmente gerenciados e qualquer reunião pode ser mantida eficiente, qualquer menor e não há valor real e qualquer maior que a equipe se torne mais difícil de gerenciar.

Capítulos

A maioria das empresas provavelmente terá uma variação menor disso, você terá uma equipe de desenvolvedores reportando-se a um gerente, e uma equipe de QA reportando-se a um gerente diferente. Nas equipes com as qual trabalho, gosto mesmo de achatar a hierarquia e remover o ‘Manager’, sempre que possível. Você pode adotar esse modelo tendo seus desenvolvedores de escritórios frontais reportando-se a um ‘lead’, desenvolvedores de back office relatando a um ‘lead’ e testadores / QA reportando-se a um ‘lead’. Se você tem desenvolvedores de pilha completa, então pode ser um pouco mais difícil, mas ainda pode ser feito.

Guildas

As guildas podem ser um pouco mais difíceis de implementar, elas exigem motivação da equipe e podem exigir algum grau de coordenação. Eu aconselharia começar com algo pequeno, identificar um problema ou algo que possa ser melhorado e reunir um pequeno grupo de membros da equipe para resolvê-lo. Atribua uma liderança ao grupo (não precisa ser uma figura de ‘chumbo’ ou de gerenciamento — é realmente melhor se não for porque ele pode dar oportunidade aos membros da equipe) e usá-lo como seu ‘piloto’. Escolheu algo técnico idealmente, algo que a equipe gostaria de trabalhar, desta forma quando outros membros da equipe verem os resultados e resultados, outras guildas seriam mais fáceis de formar. Você pode começar em áreas como:

  • Monitoramento/otimização de desempenho
  • Automação de testes
  • Segurança e vulnerabilidades.
  • Serviços & Arquitetura
  • Centro de Informações Documentação & Centralização (Wiki)

Você pode até adicionar crachás ou logotipos para suas equipes adicionar um pouco de “diversão” a ele.

Abaixo estão exemplos extraídos de um site online de jogos/apostas:

Clãs:

Equipes:

Guildas:

Tribos

As tribos são um pouco mais difíceis, e eu não aconselho você a implementar a menos que você tenha uma grande infraestrutura complicada que precisa ser dividida desta maneira. Se você tem diferentes aplicativos, como web, web móvel, cliente nativo/aplicativo nativo ou aplicativo móvel nativo, não os divida. Você está introduzindo dependências, então, é melhor ter uma equipe autônoma que possa construir um recurso e implantá-lo em todos os canais, e não ter que esperar que outra equipe seja concluída. Isso pode exigir mudanças em sua arquitetura ou processo, mas no final eu acho que é o melhor caminho a seguir.

GUILD CON

Se você realmente quer ser criativo, você pode organizar eventos para suas guildas. Um conceito que eu vim com foi ‘Guild Con’, este pode ser um dia onde cada uma das guildas apresenta aos outros sobre o que eles têm trabalhado, compartilham dicas e conhecimentos ou até mesmo tentar recrutar pessoas para participar.

Você também pode organizar ‘dias de hack’ ou desafios de equipe para suas guildas, para chegar a um novo conceito, ideia ou protótipo para ser julgado no final do dia por um prêmio.

Fazendo algo assim, dê às guildas mais um senso de propósito, e pode ser ótimo para a construção de equipes

Resumo

Há muitas maneiras de reorganizar e reestruturar suas equipes, mas lembre-se — renomear e mudar onde as pessoas se sentam não resolverá todos os seus problemas. Sua arquitetura e organização devem ditar como você quer trabalhar, não o contrário. Lembre-se, o objetivo é ser capaz de entregar produtos de alta qualidade e ser capaz de escalar. Modele como você quer que suas equipes se comportem e a cultura que você quer promover.

Algumas perguntas que você deve se perguntar são:

  • Suas equipes podem escalar com crescimento? Pense em diferentes cenários; qual é a id que sua empresa precisa para produzir um novo tipo de produto? E se sua empresa entrar em um novo mercado? E se sua empresa comprar outra empresa?
  • Você pode garantir que cada um de seus recursos ou departamentos receba a capacidade de atenção e desenvolvimento que eles merecem?
  • Você pode manter a burocracia no mínimo (veja spotify para MVB — é um ótimo conceito)? Isso é importante para escalar, então projetar, liberar e desenvolver não se torna doloroso e político.
  • Você pode garantir um planejamento rápido e um processo de liberação limpo?

Embora este método seja grande e muito idealista, ele também vem com suas dificuldades.

Por exemplo, com tantas equipes ‘micro’, pode se tornar difícil garantir que o conhecimento seja transferido, e as equipes não se tornem siloed. Isso com certeza é necessário se, por exemplo, um esquadrão precisar fazer algum trabalho em outra base de código de esquadrões, e até mesmo em um nível de produto. Todos ainda precisam estar em sincronia e indo em direção ao mesmo objetivo estratégico. 10 esquadrões indo em sua própria direção não vai ajudar ninguém. É por isso que a visão é tão importante, que eu vou cobrir em um post separado.

Se você quiser ver mais sobre como o Spotify faz isso, você pode ir aqui:

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

Este artigo foi publicado pela primeira vez em: theproducthub.io

https://www.theproducthub.io/2019/10/20/agile-team-organisation-squads-chapters-tribes-and-guilds/

Autor: Ashley-Christian

Artigo Orignal