A postagem de hoje apresente um caso real de aplicação da Metodologia Ágil e após um determinado cescimento da empresa empregou-se a metodologia para a entrega rápida de produtos. A matéria a seguir é extremamente importante para gestores que estão com dificuldades em tornar ágil o negócio principalmente pelo crescimento de seus negócios. O artigo a seguir foi escrito por Fernando de La Riva e Victor Lima, sendo o primeiro Diretor Executivo da Concrete Solutions e o segundo Gerente da área Mobile da Concrete Solutions.
" 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.

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.

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).
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:
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.
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:
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.
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
Fernando 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 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.
Bons estudos gestores e pesquisadores.
Abraço!!!!!!!!!!!!!!!!!!