BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Como escalar equipes ágeis e entrega de produtos?

Como escalar equipes ágeis e entrega de produtos?

Favoritos

A Concrete Solutions iniciou suas atividades em 2001. Cinco anos depois, após muito aprendizado e a partir de experiências empíricas e níveis muito baixos de sucesso utilizando o modelo cascata, chegaram à conclusão de que deveriam adotar métodos ágeis para seus projetos ou então seria melhor fechar a empresa. Desde então, aprenderam, evoluíram e iteraram seus conceitos e a prática de ágil muitas vezes, seguindo sempre o que dita a metodologia.

O crescimento

Com o crescimento da empresa nos últimos anos, identificamos a necessidade de realizar algumas alterações em nossa estrutura organizacional. Neste cenário, chegamos ao desafio de como escalar uma estrutura ágil de desenvolvimento de software que consiga abranger mais de 50 equipes, seja auto-organizada e que tenha poucos níveis hierárquicos, sem interferir na qualidade e cultura.

Diante deste cenário, buscamos as opções já estudadas pelo mercado e encontramos algumas iniciativas, como as que foram comparadas por Richard Dolman e Steve Spearman. Dolman e Spearman falam de no mínimo 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, o método que mais nos interessou, nomeado de "Spotify Model". Nossa percepção é que os outros seis modelos propostos têm uma teoria bem fundada, mas são pouco práticos. Para a Concrete Solutions, o que serviu de inspiração foi o modelo do Spotify, que explicaremos em detalhes a seguir.

Histórico

Quando iniciamos, nossa prática era baseada em equipes de engenharia que respondiam diretamente a um sócio. Neste experimento, o papel de Product Owner (PO) ficava a cargo dos nossos clientes. Oferecíamos uma equipe multidisciplinar e o cliente coordenava essa equipe 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 precisava administrar 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 equipes multidisciplinares.

Era a hora de adotar o papel de PO e trabalhar com ele dentro da equipe. Passamos, então, da prática de engenharia (experimento 1) a uma prática de produto (experimento 2), como exposto na figura a seguir.

Estrutura3.jpg

O modelo funcionou bem até determinado número de pessoas. Com o aumento da equipe e o surgimento novos projetos, as figuras dos POs e dos sócios ficaram sobrecarregadas com tantas referências e com a necessidade de apoiar a melhoria continuada das pessoas e das equipes e tivemos que procurar uma forma de escalar a estrutura até chegarmos no modelo do Spotify.

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

Visão Geral

As células base da Concrete atualmente são quatro práticas, mostradas na figura a seguir e 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 integrantes de cada célula não precisam necessariamente estar no mesmo lugar, são razoavelmente autoorganizados e autogeridos e usam as mesmas tecnologias.

Estrutura4.jpg

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 a computação na nuvem não gera um produto, mas ajuda no desenvolvimento dele.

Equipe base

A Concrete Solutions vende equipes 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 na equipe. Essa equipe pode sofrer algumas variações dependendo da necessidade ou não de desenvolvimento de uma API ou de tecnologias envolvidas. A seguir, temos um exemplo de equipe de desenvolvimento móvel padrão. Dentro do possível, tentamos manter as equipes trabalhando juntas durante um longo período de tempo (equipes estáveis).

3.jpg

Detalhamento da estrutura

Considerando que as práticas são divididas em Produto e Engenharia, (Web e API SP, Web e 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 Chefe de Engenharia cuida do restante da equipe, formado pelos desenvolvedores, Scrum Master, DevOps, UX e o QA. Na figura a seguir, veja a representação gráfica dessa organização:

Estrutura.png

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 e Devops).

Dentro do capítulo geralmente surge uma ou mais figuras de destaque, chamadas de "chapter leads" ou "líderes de divisão", 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, nas equipes de desenvolvimento móvel temos um líder de capítulo de Android, um líder de capítulo 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 divisão é o Chefe de Engenharia. Uma informação relevante 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 produto e descoberta do cliente) como para a área de engenharia.

No próximo passo, o PM responde para um Chefe de Produto, que fica um nível hierárquico acima, mas comanda também um grupo de POs. Na figura a seguir, 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.

5.jpg

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 nossas equipes de "equipes de pizza", aqueles que podemos alimentar com uma pizza (ou seja, oito posições). Se um PM chega até 8 POs, com até 10 pessoas nas equipes abaixo de cada PO, podemos ter até 80 pessoas abaixo de um PM. Entretanto, destacamos que o número de oito equipes abaixo de um Chefe de Engenharia pode ser um pouco alto. Depende do nível de fluência de cada equipe e do nível de complexidade de cada projeto. Entretanto, nosso cálculo nos leva a até 80 pessoas por prática, o que na Concrete equivale a um total de 240 pessoas.

Quando chegarmos a esse número é 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 das equipes

Com base na evolução e aprendizado das nossas próprias equipes, chegamos a um modelo de maturidade que se aplica na companhia como um todo, equipe a equipe, para tentar manter a garantia de qualidade. Chamamos esse modelo de "4Ps": Práticas, Papéis, Plataformas e Produto e, em resumo, significa que para fazer um produto digital de sucesso é preciso que 7 papéis (PO, Scrum Master, UX, QA, Desenvolvedores, DevOps e Growth Hacker) apliquem 9 práticas (engenharia ágil, user experience, growth hacking, descoberta de produto/cliente, execução de produto, métricas, QA, governança e cultura e organização) usando uma plataforma que envolva as melhores ferramentas para descobrir, desenvolver, entregar, testar, deployar e monitorar. Veja na figura a seguir:

4Ps.jpg

Para medir o nível de fluência das equipes, aplicamos o modelo de maturidade de forma periódica. Primeiro, avaliamos os papéis. A equipe 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, entrega contínua, 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 da equipe é 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, conforme figura a seguir.

Avaliação PO e SM.jpg

Evolução do modelo

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 equipes, 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 a equipe vai crescendo essa facilidade vai diminuindo pouco a pouco e teremos que pensar em novas práticas para compartilhar conhecimento e nivelar as equipes.

Conclusão

Assim como o Spotify anunciou logo no início de seu artigo, evoluímos rápido. Esse texto é 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 a seguir o seu comentário. Até a próxima!

Sobre os autores

Fernando1.jpgFernando de la Riva: Diretor-executivo da Concrete Solutions, consultoria global de TI, engenheiro de computação pela PUC-RJ, especialista pela Coppead, MBA pela universidade de Columbia e mestre pela London Business School, empreendedor serial, ajudou a desenvolver mais de 24 startups de tecnologia. Fundou seis empresas, produziu uma saída, uma cratera lunar, uma aterrissagem suave e três empresas operacionais. Liberal com orgulho, flamenguista, maratonista e apaixonado por Software desde os 10 anos de idade.

Victor Lima1.jpgVictor Lima: Gerente da área mobile da Concrete Solutions e sócio-fundador da CloudRetail, Victor Lima desenvolve produtos digitais desde o século passado. Começou a trabalhar com produtos mobile em 2009 e não pretende parar mais. Acredita que métodos ágeis somados a uma boa gestão de produto podem modificar a vida das pessoas. A liderança no desenvolvimento de mais de 40 aplicativos mobile possibilitou uma boa expertise em engenharia ágil, product / customer discovery e Lean Startup. Músico nas horas vagas e baterista por opção.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

  • Exemplo bacana

    by Luiz Fernando Mello,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Muito legal a forma de organização e como aconteceu as evoluções. Achei muito bacana vocês compartilharem isso com a comunidade, em geral as empresas escondem suas organização ou casos de sucesso.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT