Cultura Ágil - O modelo Nubank Squads
Tags: agile, methodologies, nubank, squads
Published: 2021-11-24 02:36:55

Neste artigo você entenderá a forma que as empresas mais valiosas do mundo estão organizando e gerenciando suas equipes promovendo uma cultura “super” ágil, a fim de manter a máxima agilidade possível na solução de problemas, mesmo depois de atingir larga escala e tornar-se gigante no mundo dos negócios. A luta contínua das empresas em manter uma cultura ágil exige muito esforço, principalmente quando se necessita escalar estas práticas para novas equipes da organização.

![Nubank](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/smfn8mc82z0nequgekxt.png)
 

Manter a cultura de startup, depois de ser agressivamente alavancado é um dos maiores desafios no mundo dos negócios exponenciais. O Nubank é uma das maiores startups da América Latina que teve um crescimento impressionante desde a sua fundação em 2012, chegando a ter 5 milhões de clientes em 2018. Para garantir uma escalabilidade saudável e sustentável desse crescimento, houve um planejamento muito bom da arquitetura do backend, associado a uma forte cultura de pessoas e processos.

Há diversas metodologias de desenvolvimento ágil de software pelo mundo que se preocupam em como priorizar e entregar as tarefas ou especificar qual deve ser o tempo da iteração, quais cerimônias para deixar a comunicação clara ou os papéis existem entre o cliente e o desenvolvimento *(product owner, scrum master, team, etc)*.

Em 2012 Henrik Kniberg & Anders Ivarsson, na época eram agile coaches na Spotify, publicaram o artigo [Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds](https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf) e em 2014 dois vídeos ([Parte 1](https://www.youtube.com/watch?v=3YrRW4u9Rl0) e [Parte 2](https://www.youtube.com/watch?v=rzoyryY2STQ)) foram divulgados explicando como a empresa estava organizando, estruturalmente, o time. Se você ainda não viu recomendo dar uma lida no [meu artigo aqui no DEV](https://dev.to/jhonywalkeer/cultura-agil-o-modelo-spotify-squads-1j2p) que menciono sobre , vou explicar de forma sucinta: basicamente, ela dividiu a equipe em pequenos grupos multifuncionais, que são responsáveis por uma única parte do sistema. Esses pequenos grupos foram chamados de *squads*.

Por exemplo, se tivermos um squad responsável pela entidade 'Cliente' de um sistema, a equipe fica com todo o ciclo de desenvolvimento desta parte. Por conta disso, cada grupo é composto de pelo menos uma pessoa que consiga desempenhar o papel necessário para desenvolver essa parte do produto. No exemplo anterior, o squad de 'Cliente' deve fazer a parte frontend e backend do sistema, além de garantir a qualidade e fazer o deploy para produção, incluindo o monitoramento e tratamento de erros. Se houver um app mobile, a equipe deverá lembrar dessa parte também. Dessa forma, esse squad tem pessoas de diferentes chapters, ou funções — pessoas da engenharia de backend, frontend e mobile. Se a empresa trabalhar com uma equipe de qualidade separada do desenvolvimento, o squad deve ter uma pessoa desse time também.

O grupo também tem autonomia para decidir o que e como as alterações serão feitas, qual metodologia de gerenciamento irá utilizar (scrum, kanban, etc) e o que mais precisar para desempenhar bem o seu papel. No exemplo acima, o squad pode decidir não fazer a parte mobile, se não houver necessidade naquele momento.

![Tribes](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m5lbsctr4nm31nu7w8r6.png)

Não irei detalhar todos os aspectos, mas deixo aqui esta figura que está no [artigo de Henrik Kniberg & Anders Ivarsson](https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf) e mostra a estrutura das pessoas em um modelo de squads. É um material bem completo e detalhado que vale a leitura. Os elementos principais dessa organização são os squads, os chapters, as tribes e as guilds.

Depois disso, soube de vários cases de empresas que estavam implantando e comentando sobre as dificuldades que passaram e ganhos que tiveram.

O Nubank é umas dessas empresas que usa este modelo de organização de times de forma bem madura. O modelo de microserviços usado no backend desde o início da empresa e a cultura de desenvolvimento, com muita autonomia e confiança, ajudou a fazer com que fosse bem fácil de usar a esta forma de organização. Apesar de a empresa ter se adaptado bem, ainda temos algumas situações a serem corrigidas, que vou comentar ao longo do artigo. Resumindo: esse método é super bom, mas pode ser difícil para muitas empresas, então não é mais uma bala de prata e nós não devemos tratá-lo como tal.

### Estrutura dos times no Nubank

Temos vários chapters: Engineer, Business Analyst (BA), Design, Data Science, Communicators e Brands Managers, Xpeer (atendimento ao público), Product Manager, etc. Alguns squads cresceram tanto que precisaram ser agrupados em Tribes, como é o caso de Acquisition e Nuconta, por exemplo.

Cada squad tem pessoas dos chapters de que necessita. Em CSD (Customer Support Design), temos Engineers, BAs, Xpeers e Data scientists (DS). Nenhuma pessoa de brand manager ou designer. Da mesma forma, em Credit Strategy, a equipe responsável por melhorar os modelos de aprovação de crédito, tem pessoas de DS, engenharia e nenhum brand manager. Já em Acquisition, a tribe que cuida de tudo relacionado a aquisição de novos clientes, tem pessoas de quase todos os chapters: engenharia, BA, Brand Manager, DS, Designer, Xpeer, PM, etc.

Os squads também podem "pegar emprestado" alguma figura de outro caso surja uma demanda específica ou, caso a necessidade fique mais frequente, estuda-se a possibilidade de colocar uma pessoa dedicada. Por exemplo, é comum os designers trabalharem em tarefas que envolvam mais de um grupo.

Também é comum a criação de Guilds para tratar de assuntos horizontais entre os squads. Desta forma, no Nubank, temos a guilda de onboarding, hiring, UI, react-native, e muitas outras para cuidar de assuntos que não são de um squad específico, mas sim de interesse de todos. As guilds servem pra apoiar novas tecnologias ou resolver problemas comuns a todos os squads. Então se alguém está com dificuldades com StyledComponents ou começou a estudar Flutter e quer saber quem mais tem interesse, podem contar com a guilda específica ou criar uma nova.

### Como é definido/priorizado as tarefas 

As demandas são definidas e priorizadas de acordo com os OKRs do squad, que são determinados de acordo com os OKRs da empresa, e com os ganhos/gastos previstos por modelos que as pessoas que trabalham como BA analisam. Se uma determinada tarefa tem potencial de fazer com que o squad atinja algum ou alguns OKR(s), então ela é detalhada, discutida com todos os chapters que serão envolvidos, antes de ser feita.

Em geral, o prazo não é o componente mais crucial de um OKR, - dado que não passamos por cima da qualidade para cumprir um prazo. No entanto, como um dos valores da empresa é *“We think and act like owners, not renters”* (“nós pensamos e agimos como donos, não como inquilinos"), a grande maioria das pessoas quer shipar - colocar coisas em produção. A idéia de entrega contínua é forte e existem ferramentas internas feitas para garantir que tudo que seja produzido, vá para experimentação do público - que as vezes são os próprios *Nubankers* - o mais rápido possível, com a maior qualidade e de forma mais eficiente. Quando algo está muito repetitivo e tomando muito tempo do time, automatizamos. Expressões como "Feedback rápido" e "vamos aprender e não ter medo de errar" são comumente ouvidas nos corredores.

Fontes onde pesquisei esse conteúdo:

- https://blog.nubank.com.br/tag/cultura/
- https://blog.nubank.com.br/cultura-do-nubank-foco-no-cliente/
- https://blog.nubank.com.br/nubank-cultura-trabalhar-de-casa/
- https://blog.nubank.com.br/nubank-metodologia-agil/