Caso Real de Equipe Ágeis e Entrega de Produtos
Autor: Daniel Canedo | Publicado: 2015-06-30T06:07:00-07:00

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.








&nbsp;

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!!!!!!!!!!!!!!!!!!