A Concrete Solutions começou em 2001. Cinco anos depois, chegamos à conclusão de que ou adotaríamos métodos ágeis para nossos projetos ou seria melhor fechar a empresa, uma vez que o nível de sucesso de waterfall era incrivelmente baixo. Desde então, aprendemos, evoluímos e iteramos nosso conceito e prática de ágil muitas vezes, seguindo sempre algum tipo de framework de trabalho iterativo e incremental.

Como é natural, crescemos consideravelmente nestes últimos 14 anos. Recentemente, fizemos algumas alterações na estrutura organizacional e emergiram melhoras de fluxo e cultura nos times que afetaram positivamente o sistema, criando um surto de crescimento no segundo semestre de 2014 e uma projeção de aproximadamente 130% no ano fiscal de 2015. Neste cenário, chegamos ao desafio de como escalar uma estrutura ágil de desenvolvimento de software que consiga abranger mais de 50 times, seja auto-organizada e tenha poucos níveis hierárquicos, sem interferir na qualidade e na cultura.

Com esse desafio, fomos procurar as opções já estudadas pelo mercado e encontramos algumas iniciativas, como essas que foram comparadas por Richard Dolman e Steve Spearman. A tabela deles fala, no mínimo, de sete métodos: Scrum of Scrums (SoS), Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Discipled Agile Delivery (DAD), Drive Strategy Deliver More (DSDM), Recipes for Agile Governande (RAGE), Scrum at Scale e, por fim, a que mais nos interessou, chamada de “Spotify Model”. Nossa percepção é a de que os outros seis modelos propostos têm uma teoria bem fundada, mas são pouco práticos. Para nós, o que serviu de inspiração foi o modelo do Spotify, que vamos explicar em detalhes mais abaixo.

Histórico

Assim que começamos, nossa prática era baseada em times de engenharia que respondiam diretamente a um sócio. Neste experimento, o papel de Product Owner (dono do produto) ficava a cargo de nossos clientes. Oferecíamos o time multidisciplinar e o cliente coordenava esse time e o produto a ser desenvolvido. Entretanto, a falta de uma estrutura de produto formal  na maior parte das empresas acabou se tornando um desafio, porque sobrecarregava o sócio que tinha que manter inúmeros backlogs além de desempenhar o papel de Scrum Master. Neste período, passamos também a ter mais contato com algumas referências de produto e chegamos à conclusão de que a nossa função é a gestão ágil de produtos, não apenas a organização de times multidisciplinares.

Era a hora de adotar o papel de PO e trabalhar com ele dentro do time. Passamos, então, da prática de engenharia a uma prática de produto.

O modelo funcionou bem até determinado número de pessoas. Com o aumento do time e o surgimento de cada vez mais novos projetos, as figuras dos POs e dos sócios ficaram sobrecarregadas com tantos reports e com a necessidade de apoiar a melhoria continuada das pessoas e dos times e tivemos que procurar uma forma de escalar a estrutura até chegarmos no modelo do Spotify, que detalhamos a seguir.

Em linhas gerais, o experimento 1 mostrou uma escalabilidade de células de até 20 pessoas e o experimento dois de até 50. Uma variável que também foi modificada no segundo experimento foi a quase totalidade de times com integração e deployment contínuo e o uso extensivo de testes automatizados. Essa melhoria de fluxo e diminuição do lote também permitiu que a estrutura o experimento 2 escalasse mais.

Visão geral

As células base da Concrete atualmente são quatro práticas, determinadas por domínio tecnológico ou critério geográfico (uma vez que temos escritório no Rio e em São Paulo). São elas: Cloud, Web/API São Paulo, Web/API Rio e Mobile. A ideia é que cada uma dessas células tenha uma área de produto e uma área de engenharia. Os membros de cada célula não precisam necessariamente estar no mesmo lugar, são razoavelmente auto-organizados e autogeridos e usam as mesmas tecnologias.

No contexto atual da Concrete, todas as células têm pelo menos um sócio responsável pela área de produto e/ou engenharia. Note que a célula de “Cloud” não é dividida e isso acontece porque cloud computing não gera um produto, mas ajuda no desenvolvimento dele.

Time base

A Concrete Solutions vende times multidisciplinares que têm o objetivo de desenvolver e evoluir um produto para um cliente. Para que possamos ser efetivos nesse posicionamento, temos que garantir que um conjunto mínimo de papéis esteja sempre incluído no time. Esse time pode sofrer algumas variações, dependendo da necessidade ou não de desenvolvimento de uma API ou de tecnologias envolvidas. Abaixo, segue um exemplo de time mobile padrão. Dentro do possível, tentamos manter os times trabalhando juntos durante um longo período de tempo (times estáveis).

Detalhamento da estrutura

Considerando que as práticas são divididas em Produto/Engenharia (Web/API SP, Web/API RJ e Mobile), surgem dois papéis de gerenciamento para cada uma delas. O primeiro deles é o Product Manager (PM), que é o responsável por gerir todos os POs da prática e a área de produto como um todo. O Head de Engenharia cuida do restante do time, formado pelos desenvolvedores, Scrum Master, DevOps, UX e o QA.

O grupo de pessoas que desenvolvem a mesma função formam um capítulo, grupo horizontal, que também se relaciona entre si e tem seus processos de desenvolvimento. Normalmente temos o capítulo de UX, de QA, de desenvolvedores em geral (Android, iOS, etc), de Scrum Master e de DevOps (este último representado pela prática de Cloud/Devops).

Dentro do capítulo geralmente surge uma ou mais figuras de destaque, chamadas de “chapter leads”, que são aqueles que têm mais fluência em uma área técnica do domínio do grupo, compartilham conhecimento e nivelam todos os membros. Por exemplo, nos nossos times mobile temos um tech lead de Android, um tech lead de iOS, etc. Este papel tem um caráter de “professor”, mas não de gerente.

Neste ponto, lembramos que existe uma prática de DevOps, que chamamos de “Cloud”, na qual o líder de capítulo é o Head de Engenharia. Outro “lembrete” que vale a pena destacar é o papel de UX, que na prática responde tanto para a área de produto (uma vez que participa dos processos de product e customer Discovery) como para a área de engenharia.

No próximo passo, o PM responde para um Head de Produto, que fica um nível hierárquico acima, mas comanda também um grupo de POs. Na figura abaixo, destacamos também o surgimento do líder de capítulo, que é o responsável por coordenar e direcionar todos os membros do capítulo do qual faz parte.

Visão de escalabilidade

Finalmente, como escalar? Basicamente, a escalabilidade é uma questão simples de números. Com essa estrutura definida, podemos chegar até a 8 POs para um PM. Informalmente, chamamos nossos times de “times de pizza”, aqueles que podemos alimentar com uma pizza (ou seja, oito posições). Se um PM chega até oito POs, com até 10 pessoas nos times abaixo de cada PO, são cerca de 80 pessoas abaixo de um PM. Na estrutura mencionada acima, a entrada de um Head de Produto permitiria que a prática tivesse em torno de 16 Product owners e consequentemente até 160 pessoas. Entretanto, destacamos que o número de dezesseis times abaixo de um Head de Engenharia pode ser um pouco alto, o que ainda não foi validado. Vai depender do nível de fluência de cada time, de quão bem funcionem os Chapter Leads  e do nível de heterogeneidade técnica dos produtos sendo feitos nessa prática. Entretanto, nosso cálculo nos leva  a um limite teórico de 80 a 160 pessoas por prática, o que na Concrete equivale a um total  de entre 300 e 500 pessoas nas quatro práticas atuais.

Quando chegarmos a esse número será a hora de criar novas práticas, novos sites e as figuras de diretor de produto, que será o responsável por todos os PMs, e do diretor de engenharia, que cuidará dos heads de engenharia. Acreditamos que o último nível seria a criação de um VP de produto, afinal nossa preferência é manter poucos níveis hierárquicos.

Fluência dos times

Com base na evolução e aprendizado dos nossos próprios times, chegamos a um modelo de maturidade que se aplica na companhia como um todo, time a time, para tentar manter a garantia de qualidade. Chamamos esse modelo de “4Ps”: Práticas, Papéis, Plataforma e Produto. Já falamos de cada um desses posts em alguns outros textos aqui no Blog, mas este resume bem a nossa posição neste sentido.

Para medir o nível de fluência dos times, aplicamos o modelo de maturidade de forma periódica. Primeiro, avaliamos os papéis. O time tem todos os papéis? Os papéis têm níveis de senioridade adequados? É um questionário simples e fazemos quase que intuitivamente. Depois, é hora de avaliar se as práticas estão sendo cumpridas, e práticas e plataforma são acertadas ao mesmo tempo, em paralelo. Afinal, não tenho como testar sem saber fazer integração contínua, deployment contínuo etc. Todas essas variáveis geram uma nota, ou um nível de fluência, que vai de zero a quatro.

Mas é claro que cada membro do time é avaliado de forma individual, considerando também o modelo de maturidade. Dois exemplos que valem a pena serem ressaltados são a avaliação do Product Owner, que passa por seis “áreas”, e do Scrum Master, avaliado em cinco instâncias. Enquanto o primeiro é medido pela fluência na área de domínio, marketing & analytics, UX e engenharia, além de ágil e lean, o Scrum Master é avaliado considerando engenharia, capacidade de facilitação do framework Scrum, remoção de impedimentos e governança e política, além, é claro, de ágil.

Desafios

Ainda estamos conversando bastante sobre as atividades de sincronização e gestão da interdependência de projetos. Afinal, temos clientes com portfólios de produtos web e mobile, que misturam times, POs e Heads de engenharia. No nível em que estamos, ainda conseguimos manter muitas conversas “one to one”, tanto entre os mesmos papéis quanto entre os gestores. Mas ao chegar em um número mais elevado de pessoas pode ser que esse esquema não funcione mais.

Também temos uma questão importante de cultura. Quando os capítulos são menores é mais fácil passar conhecimento por meio de Hangouts, eventos, conversas informais e até em happy hours. Conforme o time vai crescendo essa facilidade vai diminuindo pouco a pouco e teremos que pensar em novas práticas para compartilhar conhecimento e nivelar os times.

Assim como o Spotify anunciou logo no início de seu artigo, nós evoluímos rápido. Esse artigo é uma análise do nosso modo de trabalho atual, que está em constante transformação e aprendizado. Pode ser que quando você leia esse texto, alguma coisa já tenha mudado.

Ficou alguma dúvida, tem alguma sugestão ou gostaria de aprender mais sobre esse tema? Fale com a gente! É só deixar abaixo o seu comentário. Até a próxima!