O modelo de organização de times em Squads está ultrapassado?
Em um mundo fictício, existia uma pequena empresa de software chamada “Empresa Ficção”. Esta empresa sonhava em se tornar referência nacional, entregando valor ao cliente e utilizando o que mais tinha de novo em termos de tecnologia. A empresa começou com pequenos projetos e ao longo de pouco tempo, cresceu e demonstrou potencial de atingir o seu objetivo inicial.
A Empresa Ficção testou vários modelos de organização de equipe até chegar no modelo (talvez) ideal, no qual os times se organizariam em pequenos times composto por profissionais de perfis multidisciplinares. Esses times seriam chamados de Squads!
Durante meses, o modelo mostrou resultados e cada vez mais se via o potencial que a Empresa Ficção poderia alcançar. Porém, em seu percurso, percebeu-se que o modelo de squad não era totalmente escalável. Criar Squads exigiria contratar líderes, definir equipes e treinar pessoas, desta forma, para melhor se organizar, o modelo foi aprimorado. Neste aprimoramento, a Empresa Ficção não teria mais Squads, mas sim agrupamento de grandes times (várias Squads) com líderes em comum.
Essa história me traz uma reflexão: será que o primeiro modelo de Squad que a Empresa Ficção adotou não deu certo por causa da falta de escalabilidade ou por que o modelo não foi apropriadamente testado? Claro que não temos muitos detalhes na história para responder essa pergunta.. Mas é um contexto interessante para iniciarmos a nossa conversa.
Hoje muito se fala em “Squad”. conceito que está na moda para organização de equipes de forma ágil no Brasil. Mas a verdade é que muitos já enxergam esse modelo um pouco ultrapassado. Mas é isso mesmo? Vem comigo que eu quero mostrar alguns pontos para refletirmos juntos. Primeiramente, é necessário entender o que significa esse modelo de “Squad”que tanto se fala.
Como funciona?
Reza a lenda que o modelo de Squads surgiu no Spotify. Bem, não é claro se ele de fato surgiu lá, mas é certo que essa modelagem de equipes se popularizou por conta do case de sucesso desta empresa. Em sua busca para se tornar o mais dinâmico possível e atender as necessidades dos seus clientes de maneira rápida e clara, o Spotify organizou sua equipe em pequenos times. A ideia inicial seria que esses times tivessem a função de guiar o desenvolvimento de pequenas porções de funcionalidades (fim a fim). Chamados de Squads, eles atuariam de maneira autônoma (possuindo configurações de profissionais com perfis técnicos semelhantes e dedicados).
Muito massa essa ideia, mas o que seria “atuar de maneira autônoma?”. As Squads seriam compostas por desenvolvedores, designers, testers, Product Owner (PO), entre outros. Desta forma, eles seriam responsáveis por descrever o caso de uso, planejar o fluxo (design), desenvolver, testar, validar e entregar ao usuário final (deploy). As decisões de projeto seriam de responsabilidade da Squad e a mesma teria que seguir somente guidelines globais da empresa.
Além do conceito central (Squads), existem algumas definições que complementam a dinâmica de funcionamento dos times. Para avançamos na nossa discussão precisamos entender mais sobre isso que seria: Tribe, Chapter e Guild.
Tribe
Um conjunto de Squads que atuam em uma mesma área de negócio é denominada Tribe. Por exemplo, 3 squads responsáveis pelo desenvolvimento de uma versão mobile para um sistema desktop poderia ser caracterizada como uma Tribe. A ideia é que os membros de cada Squad pudessem interagir com outras Squads tendo o mesmo assunto em comum para discutir (dentro da mesma Tribe). No modelo do Spotify existe a figura de Tribe Leader. Mas em várias empresas isso nem sempre é adotado.
Chapter
Em diferentes Squads, temos pessoas com o mesmo perfil. Por exemplo, toda Squad possui um ou mais desenvolvedores Front-End. As pessoas que atuam em uma mesma área podem se organizar em Chapters. Os agrupamentos em Chapter buscam unir pessoas com o mesmo perfil técnico (e que atuam em Squads diferentes) em torno de objetivos específicos: discutir boas práticas e/ou aprimorar técnicas de trabalho. Nas reuniões de Chapter, a ideia é trazer discussões técnicas do dia a dia e encontrar soluções em comum que possam ajudar todas as Squads.
Guild
As Guilds possuem pontos de semelhança com a definição do Chapter. O agrupamento em forma de Guild não necessariamente precisa ser formado por pessoas com o mesmo perfil técnico. A Guild pode surgir em torno de uma mesma pauta. Por exemplo, uma empresa possui uma frente de atuação que requer constante aprimoramento de tecnologias assistivas. A empresa poderia criar uma Guild de Acessibilidade e promover debates entre seus membros em busca de melhorias em seus produtos e técnicas. Pessoas de diferentes perfis e de diferentes Squads podem participar de uma Guild.
Vamos voltar para o cenário que discutimos no início?
Agora que sabemos como funciona o modelo, vamos voltar à nossa Empresa Ficção. No início eu levantei a pergunta sobre as razões pela qual o modelo de Squads não deu certo nesta empresa. Muitos gestores aplicam o modelo achando que a solução dos problemas seria resolvido “da noite para o dia”. “Se o Spotify conseguiu, por que eu não conseguiria?”. Eis uma pergunta que muitos poderiam se fazer.
Entretanto, a minha experiência me diz que em algumas ocasiões, as pessoas analisam os resultados de ações de intervenção, mas não analisam o processo. Eu imagino que para o Spotify chegar onde chegou, foi necessário muito teste. Como eles sabiam que seria necessário interação entre pessoas com o mesmo perfil técnico (Chapter)? Dar autonomia para as Squads tomar decisões sozinhas surgiu foi algo pensado logo no primeiro modelo?
Eu não tenho respostas diretas para essas perguntas, mas participei diretamente da implantação deste modelo em uma empresa que trabalhei no passado. Posso afirmar com todas as palavras que o processo de implantação é doloroso e requer MUITO planejamento. É necessário identificar perfis técnicos que se destacam para liderar as Squads, definir como os Chapters poderão se organizar, conscientizar as pessoas que existe uma diferença na atuação dos diferentes líderes e por fim, estruturar a gestão para que os times sejam constantemente alimentados com a estratégia global da empresa.
O processo de amadurecimento do modelo até atingir o auge da operação nesta empresa que trabalhei demorou em torno de dois anos e meio. Os frutos da implantação foram inegáveis. Todo o modelo trouxe dinamismo para os times, aumentou a motivação das pessoas, tornou o ambiente mais leve e resultou em mais rapidez nas entregas realizadas por cada time. Na minha concepção, a experiência de participar dessa implantação foi maravilhosa e ver o dia a dia das Squads e como elas conseguiam amadurecer os conceitos deste modelo me deixava motivado.
A empresa Ficção do nosso primeiro exemplo decidiu mudar o modelo de Squads depois de alguns meses de implantação. A minha resposta para a pergunta que fiz logo no início é que o modelo não deu certo, pois a empresa provavelmente deu pouco tempo para amadurecimento da nova organização. Na minha experiência (que citei anteriormente), o processo de amadurecimento durou alguns anos. Talvez, a ânsia de crescer e se organizar rapidamente, não permitiu que a empresa Ficção pudesse usufruir dos benefícios da implantação das Squads.
Falando de uma maneira mais geral, existem diversas razões para empresas descartarem modelos de organização de equipes e migrarem para outros. Ando lendo algumas coisas sobre o porquê do modelo de Squads ter fracassado (deixei alguns links no fim deste artigo). Consigo concluir que essa afirmação me parece meio prematura. Na área de Tecnologia da Informação estamos acostumados a mudanças (literalmente) toda semana. Eu consigo ver tantas formas de explorar esse modelo de organização de equipes e aprimorar ainda mais a sua estrutura. Os problemas que as Guilds levantam e tentam resolver poderiam resultar em pesquisas de mestrados e doutorados, já pensou?
A empresa Ficção tem seus motivos para ter mudado a sua estrutura e abandonado o modelo de Squads. Mas eu insisto na ideia de que ela poderia ter aplicado e testado este modelo por mais tempo. Eu consigo enxergar escalabilidade e vantagens no modelo de Squads, mas é necessário que a estratégia da empresa esteja alinhada e comprometida em incorporar um modelo que exigirá uma mudança cultural importante na sua organização.
E assim, concluímos que…
o modelo de Squad de fato pode estar passando por um processo de adaptação atualmente. Como ele se tornou popular a partir de um case de uma empresa (que possui realidades muito diferentes das outras), nem tudo é possível de se aproveitar e aplicar. Por este motivo, alguns podem afirmar que ele pode não funcionar para todos os casos.
Maaas, como falei anteriormente, eu acredito muito neste modelo e sei que ele pode evoluir para uma metodologia capaz de se adaptar a diferentes realidades e trazer agilidade para times de desenvolvimento de software. Hoje já é possível citar alguns cases de sucesso além do Spotify (empresas do Brasil, inclusive). Na torcida aqui que este modelo continue se aprimorando cada vez mais!
Gostou da reflexão? Tem mais sobre o assunto aqui:
O Modelo de #SquadGoals do Spotify Falhou
Agile Team Organization: Squads, Chapters, Tribes and Guilds
