UMA ORGANIZAÇÃO DEFINIDA POR SQUADS

26 min readNov 29, 2019

Numa transformação digital, as empresas irão implementar squads teams. Mas o que são? Quais a suas origens? Como definir o foco? Como começar esse processo na organização? Quais as vantagens e desvantagens? DigitalTransformation#2

A transformação digital, a digitalização dos negócios é uma tendência que de fato veio para ficar no mundo dos negócios, desde os negócios de tecnologia até os mais tradicionais. Tem dúvidas sobre o que é esse movimento? (veja o artigo que discute as motivações de uma transformação digital, aqui).

Mas na prática, o que significa todo esse processo? O que as pessoas mais conseguem tangibilizar no dia-a-dia é uma mudança de como os times, áreas e a própria empresa se estrutura. Agile, Scrum, Kanban, Jira, dailys, Product Owner e Squads começam a povoar o o cotidiano corporativo de forma abrupta.

Apesar de esses termos estarem muito em voga, parece que pouca gente sabe ao certo explica-los em profundidade muitas vezes até estão indo trabalhar numa Squad e não entendem o histórico, como essa estrutura deveria funcionar ou para quê.

Para entender um pouco mais vamos explorar esse tema.

O que é uma SQUAD?

O squad é um time cross-funcional que possui autonomia para definir prioridades. Por mais que as pessoas tenham essa autonomia e um senso de auto-organização, elas têm os seus objetivos alinhados aos da empresa.

Nesse modelo de trabalho, não há uma figura de liderança formal. As lideranças são mais orgânicas, já que os times são autogeridos. Eles se baseiam em aspectos técnicos e funcionais do trabalho e de seus projetos.

Também não há uma divisão funcional constituída de papéis tradicionais. Todos os envolvidos em determinado projeto trabalham conjuntamente e complementarmente, criando soluções conjuntamente.

Assim, em times com essa configuração, não há mais equipe de marketing, de T.I. ou de finanças. As equipes são organizadas multidisciplinarmente, de acordo com as necessidades dos projetos da empresa.

Origens da estrutura de Squads (Você sabia que o termo vem do meio militar?)

Uma organização militar é baseada numa estrutura hierárquica. Essa organização hierárquica foi difundida desde os tempos do império romano.

Aqui no Brasil, assim como nos EUA, uma divisão é composta por algo em torno de 9.000 a 20.000 homens, que é composta por vários tipos de brigadas. Batalhões, por exemplo, são compostos por algo em torno de 800 soldados.

Pelotões são agrupamentos que se subdividem em squads ou sub-unidades táticas. O Squad é composto de um mínimo de 8 soldados e no máximo 12. Nos EUA, geralmente, são 9 soldados. O Squad geralmente pode ser quebrado no que chamamos de Fireteam, que é a menor unidade que existe, composta de 3 a 4 soldados.

Pra ficar simples: você já deve ter ouvido falar da Série chamada Band of Brothers. Essa série conta a história de uma Companhia (de 80 a 150 soldados). Já a história do filme O Resgate do Soldado Ryan, conta a história de um squad.

Geralmente um Squad é formado levando em conta um objetivo. Assim como nos jogos e nos filmes, o squad executa um determinado comando ou uma missão específica.

O modelo Spotify

A estrutura de squads ficou bastante famosa no mundo de desenvolvimento de produtos, quando o Spotify divulgou como eles organizavam seus times de desenvolvimento em meados de 2012.

No início, o Spotify era uma empresa pequena, que basicamente utilizava o framework Scrum, com seus times pequenos e multidisciplinares. Conforme o número de equipes foi aumentando, eles perceberam que algumas práticas do Scrum não faziam mais tanto sentido para eles. A conclusão foi: os princípios do Ágil são mais importantes do que um método específico.

Como resultado, o Spotify renomeou o antigo papel de “Scrum Master” para “Agile Coach”. A intenção era que o Agile Coach fosse menos um especialista em Scrum, e mais um líder-servidor capaz de estimular e suportar a melhoria contínua. A segunda medida foi passar a chamar as equipes multidisciplinares de “Squads“, ao invés de “Times Scrum”.

As Squads, além de contarem com especialistas de diferentes funções, são auto-organizados e pequenos (8 ou menos integrantes). Eles possuem responsabilidade ponta a ponta, ou seja, projetam, desenham, desenvolvem e dão manutenção aos produtos Spotify. As Squads também têm um nível elevado de autonomia: eles decidem o que construir, como construir e como trabalhar juntos para construir. Coisa que muitas organizações nem sequer experimentam.

Obviamente, a autonomia das Squads não é infinita. Algumas restrições afetam esse nível de liberdade: geralmente a missão da própria Squad (toda Squad tem uma), a estratégia geral de produto e objetivos de curto-prazo negociados a cada trimestre.

Essa estrutura potencializa a autonomia, que por ser um motivador intrínseco forte, torna as pessoas mais felizes. Além, a estrutura em Squads dá muita velocidade, pois evita esquemas de aprovação, afunilamento de decisões no topo e dependência de outras equipes.

Mas segundo o Kniberg, autonomia não é o suficiente para construir produtos incríveis. Ele afirma no vídeo que alinhamento (em inglês, alignment) também é vital para o modelo Spotify. Em linhas gerais, todas as Squads precisam estar “alinhados” com a estratégia da empresa, objetivos trimestrais e outras Squads. A missão do Spotify como organização é mais importante do que a missão individual de qualquer Squad.

Para possibilitar o alinhamento sem sacrificar a autonomia, o papel da liderança no Spotify torna-se muito mais comunicar qual problema deve ser resolvido e porquê. O como o problema será resolvido é tarefa das Squads.

Se você perceber, o Spotify escolheu essa estrutura de forma orgânica. Ela funcionou porque durante um bom tempo fez sentido pra eles. Mas eles não se fixaram nessa estrutura que continua mudando de forma orgânica de acordo com as descobertas do time. A essência (Autonomia e Alinhamento) continua, mas a estrutura pode ser totalmente diferente.

Esse formato foi tão “inovador” para época, que as pessoas começaram a copiar loucamente nas suas empresas. Hoje, várias “empresas de tecnologia” usam esse formato, ou pelo menos acham que usam. E é ai que esta o grande problema.

O Spotify, que criou esse modelo de Squad, já evoluiu seu próprio modelo e hoje, não adota essa estrutura de forma dogmática.

Na maioria das vezes várias empresas usam a ideia original do Spotify, sem fazer adaptações a realidade da própria empresa. E com isso muitas empresas ficam no meio do caminho, pregando o vocabulário ágil, com muitas squads sem orquestração e ao mesmo tempo continuam sob uma estrutura hierárquica forte.

Um cenário típico é que empresas que não adotam os princípios ágeis e/ou não tem um plano definido de transformação digital, acabam vivendo o “pior dos dois mundos”. Nem consegue os benefícios da agilidade nem se liberta da longa estrutura de report e top down.

É normal passar um tempo em transição de um formato para outro. Mas se o tempo passa demais, a transição fica permanente e os times vivem num pesadelo onde problemas irão acontecer o tempo inteiro. Mas uma organização de TIMES é diferente de uma organização de Squads. Um time e um Squad podem se parecer bastante em alguns pontos, mas eles são organizados de forma essencialmente diferente.

Quais as características de uma Squad

Essa estrutura de Squads é muito parecida com a estrutura do Squad militar que expliquei a cima. Os Squads fazem parte de grupos maiores: Chapters, Guilds e Tribes. Vamos falar um pouco sobre essas estrtuturas.

Objetivos do Squad
Num Squad, os objetivos são bem claros. E os desafios enormes de diversos. Uma hora você precisa resolver problemas de aquisição de clientes, outro momento na experiência de atendimento do usuário e assim por diante.

Cada squad pegará um objetivo priorizado, que é importante para empresa. É bem diferente trabalhar assim, mas a empresa pode ter uma lista de prioridades criada pelos stakeholders, PMs e quaisquer outros personagens, como um backlog enorme. Não importa qual o objetivo, uma squad será montada de acordo com esse objetivo, levando em conta as especialidades e força de trabalho que o objetivo demandar.

Tamanho
O Scrum diz que um time bom pode ter de 3 a 9 integrantes. Um time muito grande gera muita coordenação para garantir a comunicação, gerando complexidade. Um time muito pequeno, perde interação e a produtividade é afetada.

Quando um time começa a ficar maior do que 9 integrantes, ele deveria ser quebrado em dois times, obviamente dependendo da estrutura que a empresa optou, novos papeis podem surgir nesse processo.

Responsabilidade
Quando um bug é encontrado em um determinado ponto do sistema, quem é acionado para resolver? O Squad que liderou mudanças na parte do sistema que o bug foi encontrado pode ser o responsável pela resolução, ou os times podem se organizar para encontrar os integrantes que mais conhecem daquela parte do sistema, ou um squad pode ser montado para resolver bugs conhecidos… são várias soluções possíveis mas a resposta correta se dará de acordo com cada estilo de empresa.

É muito mais fácil trabalhar em formato de Squads em uma empresa onde os integrantes são experientes. Em ambientes de Squad, o senso de missão deve ser bem alto. Missão dada é missão cumprida.

Autonomia
Os squads precisam ter todas as especialidades no grupo para completar seu objetivo de forma independente. A ideia é que se houvesse um ataque zumbi, essas pessoas conseguiriam fazer deploy sem depender de ninguém.

Autonomia e alinhamento são as palavras chave de um Squad.

Dado que temos um problema, esse problema precisa ser resolvido de alguma forma. Quem vai decidir COMO resolver aquele problema é a Squad. Não é o Stakeholder. Não é a diretoria. Os squads precisam ter autonomia para descobrir a causa raiz e decidir como atacar aquele problema. Além disso o alinhamento deve fazer parte do processo interno da Squad e também de forma global. Como as partes do sistema não tem um dono específico, todas as Squads precisam ter um alinhamento intenso, se não a coisa toda desanda.

Estrutura e organização das Squads

A estrutura interna das equipes da Spotify sofreu enorme influência de práticas ágeis (Agile, Scrum, Extreme Programming, etc), de autores como Tom e Mary Poppoendieck e Tom DeMarco, além de conceitos de auto-gestão, ligados às metodologias ágeis, como Jurgen Appelo.

A organização básica é a matriz com times orientados vertical e horizontalmente. Os grupos orientados verticalmente (squads e tribos) são agrupados por produto, ou seja, por features ou grupos de features correlacionados. Os grupos orientados horizontalmente (chapters e guilds) são agrupados por skill ou interesse, e têm como objetivo a troca de melhores práticas, experiências, e desafios, onde a empresa tenta obter sinergias internas de conhecimento e produtividade.

Por serem bastante auto-geridos, nos times não existem figuras tão marcantes de liderança formal, mas sim lideranças mais orgânicas, bastante fundadas nos aspectos técnicos/funcionais do trabalho. Assim, apenas chapters e squads tem lideranças claramente identificadas. O product owner direciona o quê é feito (WHAT), e o líder de chapter direciona como isso é feito (HOW).

Squads
Squads são a unidade básica de organização dos times, usualmente em torno de uma feature, ou subsecção de uma funcionalidade. Podem ter de 3 a 10 membros, e devem ser autônomas a ponto de conterem expertise dentro do grupo para desenvolver todos os aspectos do produto: da concepção à prototipação, design, desenvolvimento, e deployment.

Estrutura de uma squad
Com todos os perfis necessários, os squads têm a autonomia para tomar as melhores decisões sobre a funcionalidade pela qual é responsável. Cada vez mais os times de desenvolvimento de produtos digitais têm se especializado em diversos papéis. Normalmente os times são compostos de:

Product Owner ou Dono do Produto (PO): responsável pela definição de produto, de acordo com suas funcionalidades. Deve ter uma visão geral de todas as sprints e gerenciar o backlog, priorizando as tarefas. O Product Owner é quem diz ao time o que ele tem que fazer e quando. Basicamente, o PO é o “Chief Executive Officer” (CEO) do produto.

Scrum Master (SM): garante que todas as práticas ágeis sejam seguidas. O SM protege o time para que ele não se comprometa com mais do que pode desenvolver e gerencia as expectativas dos stakeholders, além de resolver problemas de relacionamento entre o time e impedimentos externos que possam atrapalhar o desenvolvimento. O scrum master é o “coach” ágil do time.

User Experience (UX), Designer ou Designer de Experiência de Uso: age como ponte entre o desenvolvimento e o usuário final, cabendo decidir o design e o fluxo que as informações devem seguir. Define também quantas telas, o que terá em cada tela, lugares de cada link e etc. O UX é quem define a usabilidade do produto.

Equipe de Desenvolvimento pode ter de uma a sete pessoas, que não têm funções pré-definidas. A equipe é autogerenciada e auto-organizada, isto é, seus membros elegem o responsável por cada tarefa e cobram sua realização. O time deve apresentar todos os perfis necessários para a execução do trabalho e é a responsável pelo desenvolvimento do produto.

DevOps responsável por codificar a infraestrutura na qual será montado o produto. O DevOps cria uma documentação viva do ambiente, que pode ser reutilizada.

Tribo
A tribo (tribe) é o segundo nível de agrupamento, e pode conter uma série de squads que tenham funcionalidades e objetivos similares. Os squads de uma tribo ficam fisicamente próximos uns dos outros, para que haja comunicação fluida.

O tamanho máximo de uma tribo segue, no Spotify, a limitação do número de Dunbar, ou seja, em torno de 100 pessoas: número derivado de pesquisas biológicas e evolutivas que mede a quantidade máxima de espécimes que tendem a conviver juntos em “sociedade” na natureza. Em tese, o ser humano não seria capaz de manter contato social (razoavelmente próximo) com mais de 100 outros humanos, número este que vem sendo constantemente desafiado pelo advento das redes sociais.

Por fim, os squads-membro das tribos se encontram periodicamente para sincronizarem seus esforços, apresentarem seu trabalho, e trocarem experiências.

Chapter
O chapter é um grupo horizontal (portanto orientado por função/afinidade) que congrega profissionais com responsabilidades e skills parecidos. Pode haver, por exemplo, um chapter de designers de UI, ou de desenvolvedores web de front-end.

Chapters são agrupamentos de pessoas com mesmas competências

Chapters são geralmente contidos dentro de tribos, e se encontram com frequência para troca de idéias, melhores práticas, e desafios que estejam enfrentando. No chapter, há um líder, que serve como “técnico” e guia o aprendizado e o desenvolvimento funcional dos membros.

Guilda
Guildas, são talvez os grupos mais difíceis de se definir no Spotify. Uma guilda é um grupo de profissionais, que pode ser de squads e tribos diferentes, e que se une para trocar experiências, aprendizados, e melhores práticas sobre temas de interesse comum.

substantivo feminino associação que agrupava, em certos países da Europa durante a Idade Média, indivíduos com interesses comuns (negociantes, artesãos, artistas) e visava proporcionar assistência e proteção aos seus membros.

Guildas são mais orgânicas e amplas comunidades de interesses, com objetivo de compartilhamento de conhecimentos.

Em muitos casos, a guilda é composta por chapters correlacionados (por exemplo, todos os chapters de designers de todas as tribos da Spotify) somado a alguns “agregados” de outras áreas que se interessem pelo tema. As guildas costumam ter coordenadores, que lideram os temas a serem discutidos e organizam os encontros.

Como definir a “responsabilidade” da Squad?

Muita gente tem dúvida de como definir a responsabilidade de uma squad. Ela irá cuidar de uma etapa da jornada, de uma feature, de um canal de um grupo de features?

O agrupamento por produto desponta como provável estrutura ideal que maximiza a colaboração de profissionais com áreas de expertise diferentes, e ao mesmo tempo maximizando a qualidade e quantidade do output através da metodologia ágil.

Por exemplo, vamos imaginar que um dos squads da Spotify seja responsável pelo motor de recomendação de músicas e bandas presente na home do aplicativo web. Essa equipe é composta por um engenheiro de back-end, que liga essa funcionalidade aos algoritmos da empresa; por um engenheiro de front-end, que programa a interface visual; por um designer, que desenha a UX e a UI dessa funcionalidade; e por um engenheiro de operações, que cuida do deployment do código.

A responsabilidade de diversas squads num único produto.

Podemos atribuir um resultado claro a essa equipe? Se as recomendações forem boas, imaginamos que a taxa de cliques nas músicas e bandas recomendadas será mais alta. Além disso, ao clicarem e ouvirem/testarem mais de perto as recomendações, os usuários adicionarão mais recomendações às suas playlists à medida em que forem melhores as próprias recomendações. Portanto temos duas taxas de conversão que podem se tornar as metas/KPIs de resultado a serem medidos como proxy da performance do time.

Pois bem. Mas poderíamos quebrar esses resultados de negócio a cada um dos membros da equipe, para que possamos medir exatamente a performance de cada um? Será? Quanto do resultado das taxas de conversão pode ser atribuído ao engenheiro de back-end, vis-a-vis o designer? Impossível. Assim, dada essa grande dificuldade, gestores e líderes pelo mundo passam a atribuir metas de esforço a esses profissionais: se o designer cumprir com todas as necessidades do time nos sprints, ele terá performado. Algumas empresas estabelecem cerimônias de avaliação das entregas, que passam, se aprovadas, a serem ‘contabilizadas’ como resultados entregues.

No entanto, é importante ressaltar que esforço — nesse caso a entrega das telas prontas pelo designer dentro do prazo estipulado pelo time — não é sinônimo de resultado. O resultado é unicamente passível de mensuração pela taxa de conversão de usuários (ou outra medida de negócio estabelecida pelo time). Fazer exercício não é sinônimo de emagrecimento.

O foco desse estudo de caso não é discutir o tema de performance em times multifuncionais , mas é importante que as empresas praticantes do Agile e da organização de times de produto como a da Spotify entendam que não há fórmula simples adaptável à sua realidade, e que metas individuais não serão a resposta. Será absolutamente necessário que a performance de cada membro de um squad seja uma função dos resultados de negócio produzidos pelo próprio squad e por uma avaliação 360-graus, subjetiva, da contribuição desse membro para a performance do time, no formato de idéias, resolução de conflitos, liderança emergente, priorização, etc.

Como estruturar as Squads?

O importante nesse processo inteiro é encontrar uma estrutura que funcione na sua empresa. Copiar o formato de uma empresa pode não ser uma boa escolha exatamente porque aquela empresa resolveu o problema dela, que geralmente é diferente do seu.

Todas as empresas tem alguns problemas comuns na área de desenvolvimento, mas isso não quer dizer que a solução usada em uma empresa vai resolver o problema de estrutura da sua empresa. O Spotify sim criou o formato inicial que foi disseminado, mas várias outras empresas, inclusive brasileiras, tem suas próprias formas de estruturar times.

Leve em consideração a cultura da empresa, conhecimento da área de tecnologia, a dinâmica do mercado, a dinâmica dos seus clientes, turnover dos desenvolvedores e designers, comunicação com as outras áreas, até a forma com que os stakeholders e a diretoria querem receber reports pode influenciar no formato a ser escolhido.

Um Squad é semelhante a um time Scrum, mas é projetado para se sentir como uma mini-startup. Eles se sentam juntos e têm todas as habilidades e ferramentas necessárias para projetar, desenvolver, testar e liberar aplicações para produção. Eles são uma equipe auto-organizada e decidem sua própria maneira de trabalhar — alguns usam sprints do Scrum, alguns usam o Kanban, alguns usam uma mistura dessas abordagens.

Como iniciar a transformação na sua empresa?

Cada empresa que deseja começar o processo de Transformação Digital adota um modelo. O que, pela minha experiência é a forma que mais funciona é começar devagar.

Escolha uma área da empresa que seja muito relevante
Entenda qual o produto dessa área que é o mais relevante
Elenque quais os principais problemas do produto
Quais desses problemas tem o maior impacto no resultado que a empresa esta buscando neste período
Defina indicadores de desempenho claros para medir esse problema
Tenha clareza do seu baseline — qual o verdadeiro status atual desses indicadores
Crie uma Squad para resolver esse problema — escolha pessoas seniores e perfis suficientes para que tenham autonomia ponta a ponta para solucionar a questão
Defina um OKR para sua Squad
Alinhe com todas as áreas da empresa que tenham profissionais envolvidos para que deem suporte as demandas vindo da Squad
Use o agile scrum da forma como foi descrito no manifesto antes de fazer alterações
Acompanhe os indicadores de forma constante e faça alinhamentos quinzenais ou mensais com o time

Assim, com um case de sucesso em mãos, é possível mostrar para a empresa que essa forma de trabalho traz vantagens para o negócio. A partir de então é possível começar a escalar os Squads e em pouco tempo sua organização terá uma estrutura mais ágil.

De outra forma, se quiser implementar o ágil como um todo na organização, isso dependerá de muito alinhamentos, muito investimento, contratação de pessoal, consultoria e movimentação em toda a empresa. A tendência desse tipo de movimento é que ou demore muito para sair do papel ou que fracasse por que muita gente tem aversão a mudança e remará contra essa implantação, o que pode comprometer a implantação de um modelo organizacional que vá trazer bons impactos para o seu negócio.

Quais os desafios que uma abordagem de trabalho por squads traz para a organização?

DESAFIO 1: Orientação por produto e os desafios com o PMO da sua organização

Em empresas tradicionais, times são mobilizados através de projetos. A criação de um projeto é o que forma um time. E quando um projeto termina o time é desmobilizado.

Quando falamos de Squads, buscamos times permanentes que constroem e sustentam produtos de negócio. Enquanto o produto de negócio existir, haverá uma ou mais Squads que irão cuidar desse produto de negócio.

Essa já é uma das principais diferenças entre produtos e projetos. Algumas das abordagens possíveis para lidar com essa questão incluem:

1.Operar abaixo do radar do PMO (mais conservadora)
Quando você tem um PMO muito arcaico ou resistente, pode ser impossível buscar uma mudança de abordagem. Operar abaixo do radar implica que você possui Squads internamente dentro da sua TI com o propósito de evoluir produtos de negócio, mas a linguagem de comunicação com a empresa e interessados de negócio ainda será a linguagem de projetos.
Isso exige que você faça uma prospecção ativa de projetos para conseguir garantir a orçamentação do seu Squad ou de pelo menos uma parte das pessoas do seu Squads. Isso pode implicar em que sua Squad precise cuidar de mais de um produto para que seja possível financiá-la.

2.Negociar a orçamentação anual por produtos de negócio, mas estabelecer uma lógica de desembolso centrada em projetos (intermediária)
Nessa abordagem o PMO tem ciência dos Squads e do seu propósito. E ao mesmo tempo você não quer mudar a lógica de funcionamento de um PMO, que poderia gerar muita resistência. Em conjunto, vocês e a diretoria buscam estabelecer um limite orçamentário para um produto ao longo de um ano fiscal. E esse orçamento será investido através de projetos do PMO que irão financiar uma Squad durante esse ano fiscal.
Observe que nessa abordagem não basta medir o sucesso financeiro baseado em métricas míopes de projetos como o CPI ou SPI. Devemos ir além e medir o retorno financeiro trazido para a organização no investimento em um produto de negócio. Squads devem ser medidas, primordialmente, pelos resultados de negócio que seus produtos trazem.

3. Transcender com o conceito de projetos. #NoProjects (mais agressiva)
Algumas empresas sublimaram o conceito de projetos e trabalham com o conceito de fluxo continuado de valor de negócio. Nessa abordagem você estabelece em base periódica (ex. trimestre) uma orçamentação para uma Squad. Você prioriza os itens mais importantes do bacilo que cabem naquele período de tempo. E você mede periodicamente como foi a agregação de valor de negócio por essa Squad.
Se a agregação de valor foi frutífera, você coloca mais investimento naquela Squad. Se os resultados na perspectiva de negócio são ruins, você desmobiliza a Squad e reorienta o seu dinheiro para onde fizer mais sentido.O excelente eBook chamados #NoProjects , publicado em 2016, traz casos reais e como esse polêmico princípio poderia ser discutido em organizações mais ousadas.

DESAFIO 2: Construção e Sustentação de Produtos

Em empresas tradicionais, a área de desenvolvimento desenvolve produtos. E uma outra área, chamar de sustentação, sustenta produtos. Isso parece natural, mas é uma dicotomia que gera um sistema de incentivos que leva que:

uma parte das pessoas busque entregar código o mais rapidamente possível em produção, mesmo que seja lixo
uma outra parte que é paga para atender incidentes em produção.

Esse modelo cria dedos apontados para os “culpados” pelos problemas de qualidade e incidentes.

Em Squads, temos um time que cuida do desenvolvimento de novas funcionalidades e da sua sustentação. Mas isso não é fácil. Isso exige muita maturidade.

Algumas abordagens que podem ajudar na implementação desse modelo incluem:

1.Possuir uma pessoa dedicada para sustentação na Squad (mais conservadora)
Temos aqui em uma Squad uma ou mais pessoas que irão cuidar da evolução do produto na perspectiva de negócio. E teremos outras pessoas que irão cuidar do atendimento a incidentes de produção e manutenções adaptativas.

2.Possuir uma ou mais pessoas dedicadas para sustentação na tribo.
Nessa abordagem temos uma pessoa dedicada, mas ela é da tribo e é compartilhada pelo conjunto de Squads que compõem essa tribo. Isso dilui o custo da sustentação entre Squads e permite que a pessoa da sustentação lide com mais assuntos.

3.Possuir pessoas dedicadas para sustentação em uma Squad, mas com rotação de papéis.
Se uma pessoa que não foi contratada como analista de suporte ficar muito tempo cuidando de defeitos ele pode ter o seu moral reduzido e perder a motivação.
E então você pode experimentar o “motorista da rodada”, i.e., alguém que ficará apenas alguns dias ou semanas cuidando da sustentação. Depois dessa período, outras pessoas assuem o papel da sustentação.

4.Estabelecer que todas as pessoas criam novas funcionalidades mas também sustentam os produtos da Squad. (mais agressivo)
Essa é uma estratégia complexa e requer diversos pontos que precisam andar alinhados:
O time entregue já código de excelente qualidade em produção, de foram que os incidentes sejam eventuais e o time seja pouco impactado por mudanças emergenciais.
O tamanho da mudança evolutiva seja pequena. Grandes mudanças evolutivas trazem impacto maior em ambiente de produção e isso acarreta em um maior número de incidentes, que impacta o planejamento e o moral do time.
O time use estratégias modernas de implantação como Implantações Canário. Discuti essa técnica aqui no contexto de práticas DevOps.

DESAFIO 3: Time de especialistas generalistas

Na maior parte das TIs os arranjos são funcionais. Isso é, existe a área de analistas, a área de desenvolvimento. Existe a área de qualidade ou a área de implantação. E eles se comunicam primordialmente pela ferramenta inventada pelo capeta corporativo, o famoso e-Mail. É mais que provado que essa separação de funções é ruim financeiramente falando e cria apenas silos gerenciais, disputas de poder e burocracia desnecessária.

Squads não operam de forma funcional. Em Squads maduras, temos todas as competências necessárias para criar e sustentar os nossos produtos de negócio.

Mas não é fácil chegar aqui e precisamos de abordagens intermediárias. Algumas delas incluem:

1.Estabelecer Squads de Suporte globais para funções raras na organização. (mais conservadora)
Por exemplo, poucas TIs possuem uma profusão de especialistas de segurança. E isso pode impedir que na prática tenhamos Squads com um especialista dedicada para segurança da informação.Um Squad de suporte é um tipo particular de Squad que oferta funções especializadas para outros Squads.
Esses squads podem possuir modelos de trabalho baseados em sistemas Kanbans, que lidam com demandas em base diária e promovem a vazão e o aumento da velocidade no atendimento a essas demandas.Outros exemplos de funções que normalmente podem ser acomodados nesta configuração incluem Squads de Infraestrutura, Squads de Designers Gráficos ou Squads de Arquitetura.

2.Estabelecer Squads de Suporte em tribos para funções com baixa disponibilidade
Vamos assumir que você tenha uma tribo com 25 pessoas, mas possua apenas 3 analistas de testes, Nesse cenário você estabelecer uma Squad de Suporte de Testes que irá ofertar funções para a sua tribo. Como a sua tribo cuida de produtos de negócio correlatos, não é difícil que analistas de testes possam transitar entre essas Squads e com isso ofertar uma economia de custos sustentável.

3.Aceitar os limites da sua Squad conforme o orçamento da sua organização
No mundo ideal, a sua Squad terá analistas de requisitos, engenheiros de usabilidade, arquitetos, desenvolvedores, testadores, especialistas em segurança da informação e analistas de infraestrutura.No mundo real, você provavelmente terá muito menos papéis disponíveis. Aceite a realidade e cresça a maturidade da sua Squad ao longo do tempo.

DESAFIO 4: Vencer o “modelo comando e controle”

Tradicionalmente, os gerentes estão envolvidos em decidir qual é o trabalho real e na decisão de como fazê-lo.No contexto de Squad, a decisão do que a equipe está trabalhando não está mais sob o controle do gerente, mas é decidida pelo Product Owner. O PO tem uma visão geral do produto e o que é mais valioso para os clientes, e ele prioriza o trabalho que a equipe realizar.E a decisão sobre como a equipe deve funcionar é delegada à equipe. A equipe é focada no autogerenciamento e, juntos, precisam refletir sobre o que deve ser feito e decidir como farão isso e como vão melhorar.Mas o que faz o gerente no mundo ágil?

Os gerentes atuam como construtores de capacidade. O papel da gerência intermediária é enxergar o todo e construir a capacidade da organização de construir ótimos produtos. Ele deve ajudar a equipe e o Scrum Master na remoção de obstáculos e melhorias. O Gerente deve ensinar a equipe a melhorar e resolver problemas, além de verificar formas para entender o que realmente está acontecendo no local de trabalho e ver como ele pode ajudar melhor a equipe a melhorar seu trabalho.

Algumas abordagens para vencer o modelo “comando e controle” incluem.

1.Definir o gerente de projeto como SM (mais conservadora)
Como o SM participa em base diária do trabalho do time, isso pode acalmar o ímpeto do comando e controle de gerentes mais centralizadores. Ao mesmo tempo, devemos ficar atento e impedir que os gerentes façam micro-gerenciamento (decidir como um participante do time deve fazer o seu trabalho técnico).

2.Definir o gerente de projeto como PO
O PO tem controle sobre o backlog e isso também pode ajudar que pessoas mais centralizadoras topem participar dentro de uma dinâmica ágil.

3.Adotar práticas do Management 3.0 (mais agressiva)
O Management 3.0 é um conjunto de práticas gerenciais centradas em uma mentalidade moderna de gestão.. Essas práticas podem ser adotadas individualmente ou em conjunto e permitem que o modelo de autonomia seja gradativamente instalado na Squad. Listamos aqui esse conjunto de práticas com os links para a sua descrição e uso: Business Guilds & Communities of Practice, Metrics Ecosystem, Celebration Grid, Moving Motivators & CHAMPFROGS, Copilot Programs, OKRs (Objectives & Key Results), Competency Matrix, Personal Maps, Corporate Huddles, Project Credits, Culture Books, Problem Time, Delegation Board, STAR Behavioral, Recruitment Questions, Exploration Days, 12 Steps to Happiness, Feedback Wraps, Salary Formula, Happiness Door, Scoreboard Index, Identity Symbols, Unlimited Vacations, Improvement Dialogues, Value Stories, Improv Cards & Storytelling, Visual Goal Setting, Internal Crowdfunding, Work Expos, Kudo Box, Work Profiles, Meddlers, Yay! Questions, Merit Money.

A implantação de Squads é um movimento importante na evolução da agilidade em organizações. Ao mesmo tempo, os modelos de implantação não são únicos e é fundamental você conduzir experimentações dentro da realidade da sua organização.

Na prática, os squads de uma empresa trabalham com foco na jornada do cliente e no atendimento personalizado, visando performance e um relacionamento duradouro com cada usuário/cliente. Empresas que atuam com squad team costumam integrar diferentes perfis profissionais, colocando lado a lado jornalistas, designers, profissionais de data analytics, desenvolvedores, gerentes de customer experience (CX), customer success (CS), especialistas em social mídia e mídia paga.

Muitas vezes os squads operam por segmento, atendendo, por exemplo, educação, tecnologia, construção civil, entre outros. Como comentamos antes, os profissionais que formam um squad team trabalham juntos durante todo o projeto, planejando, desenvolvendo, implementando, medindo e criando novas ações para buscar e superar as metas estabelecidas.

Cada squad possui um customer success (CS), que é o product owner, ou seja, a pessoa responsável por definir as prioridades de cada projeto. Esse profissional é que direciona o trabalho da equipe, com todos trabalhando de forma conjunta e apresentando ideias inovadoras para que os resultados sejam atingidos.

Vantagens e desvantagens

Quais são as vantagens de adotar essa configuração em uma empresa?

Comunicação
Uma das principais vantagens de contar com squads é o impacto na comunicação. Apesar de ela exigir muito mais dedicação para que dê certo, uma vez conseguida se torna uma grande vantagem sobre o modelo tradicional.

Normalmente, dois analistas de sistemas têm muito mais facilidade de interagir em seu trabalho do que um analista de sistemas e um analista de negócios, certo? Portanto, os times cross-funcionais tornam a comunicação da organização mais eficiente. Tudo isso por meio do exercício constante e da empatia. Investir em atividades que tenham como objetivo o aumento da coesão do time são essenciais e favorecem assim um clima organizacional positivo e produtivo.

Por meio de times cross ocorre a quebra de barreiras existentes entre os departamentos. Garantindo maior integração e velocidade nos processos de tomada de decisão e burocráticos da empresa.

Velocidade
As squads trazem velocidade na implantação de novos projetos pois, com um time formado por especialistas de diferentes áreas, trabalhando focado em um objetivo em comum, com autonomia e skills suficientes para entregar soluções de ponta a ponta, o desenvolvimento dos projetos ocorre de forma muito mais rápida e efetiva.

Quanto mais unido e sensibilizado em relação aos objetivos o squad for, maior será o benefício para a empresa e para a agilidade de seus processos.

Criatividade e inovação
Outro diferencial deste modelo é que as equipes apresentam um nível de criatividade maior para a resolução de problemas. Isso porque ter diferentes pontos de vista sobre determinada questão ajuda a chegar a resultados mais inovadores e adequados à realidade de cada cliente.

Tomada de decisão
Mais uma vantagem do squad team é que ele permite uma tomada de decisão mais assertiva e com foco em resultados. Como cada equipe funciona como uma mini empresa, de forma integrada, independente e com foco em cada projeto e cliente, os processos decisórios são mais ágeis e, ao mesmo tempo, mais eficientes.

Mas há desvantagens no formato de squads cross-funcionais?

Alinhamento estratégico
Uma das maiores críticas ao modelo de squad diz respeito à autonomia, já que esse tipo de estrutura permite que os membros definam as prioridades, isso gera certa insegurança na liderança de quanto alinhado as decisões na ponta estarão com os objetivos corporativos.

Portanto, é preciso garantir que haja de fato um bom plano estratégico para a empresa, sólido e que não tenha mudanças abruptas. Garantir a comunicação com todas as áreas do plano. Definir muito bem o roll out deste plano para toda a empresa e principalmente ter uma gestão adequada de metas, objetivos e indicadores, para todas as áreas e squads da empresa.

Sendo responsáveis por um conjunto de indicadores, as squads conseguem ter autonomia para decidir como executar e priorizar as atividades e estórias que garantam o atingimento dos objetivos da empresa de modo assertivo.

Estrutura e cultura organizacional
Dependendo da cultura organizacional, implantar uma estrutura de squads com times cross-funcionais pode ser uma tarefa difícil, pois isso exigirá a re-definição dos papéis dentro dos times, pessoas saindo de determinadas áreas (fisicamente), uma divisão de poder e horizontalização da estrutura da organização.

Em toda transformação existe uma certa dificuldade de aceitação, ainda mais quando essa transformação envolve a cultura organizacional. Esteja bastante atento em relação à comunicação, pois ela passará a ser muito mais direta, eliminando parte da burocracia, o que pode causar algum estranhamento.

Também a linha de reporte e gestão entre áreas e diretorias deve ser muito clara e alinhada evitando situações em que não há reporte nenhum ou em que há múltiplas linhas de reporte.

Responsabilidade
Uma vez organizada por squads, a resolução de problemas torna-se responsabilidade dos seus integrantes, por isso eles devem estar cientes e bem preparados para reavaliar seus hábitos de trabalho e assumir tal responsabilidade.

Essa estrutura exige adaptações dentro da empresa, como programas de desenvolvimento de liderança, gestão de desempenho e novos aprendizados. Assim, a integração da cultura de squads será muito mais tranquila.

Falta de um líder claro
Em muitos casos os profissionais sentem falta de um “line manager”, ou seja, uma figura única que será responsável pela liderança de todo o time. O Product Owner é o visionário do produto. Muitas vezes tem menos experiência profissional do que os membros do squad e não tem a responsabilidade de liderar temas como feedback, coaching, gestão de carreiras, etc.

Por outro lado, o líder de chapter às vezes está pouco presente no dia-a-dia do profissional, e foca, por interesse pessoal, muito mais nos aspectos técnicos do trabalho. Mas na prática é ele que deveria ser o gestor funcional do profissional, fazendo feedbacks e cuidando dos seus assuntos de carreira, , desenvolvimento, etc.

Pouca visibilidade de desenvolvimento
Outro problema presente nos squads multifuncionais, mas que deriva de uma dificuldade mais ampla de equipes altamente colaborativas, é a dificuldade de achar accountability clara de desenvolvimento individual. Empresas estão acostumadas a sistemas quantitativos, que possam quantificar performance como uma nota. Por isso, tendem a preferir cortar caminho e atribuir metas individuais aos funcionários, sejam eles engenheiros de software, vendedores, ou designers. Mas sabemos que metas boas são metas de resultado de negócio, e fica extremamente difícil conseguir atribuir um resultado de negócio a um indivíduo em um time multifuncional.