Agilidade em escala corporativa

Escalar o Scrum é uma tarefa extremamente complicada. Quando comecei a trabalhar com Scrum em 2010, era minha responsabilidade aplicar a metodologia em apenas um time que era crítico para a empresa. E deu super certo. De lá para cá a complexidade foi aumentando e desde minha passagem pela Umbler que a necessidade de escalar o Scrum e os problemas que isso traz se tornaram evidentes.

Atualmente no Banco Agiplan, uma corporação com centenas de funcionários apenas na sede em Porto Alegre (e milhares em todo Brasil), aplicar agilidade em escala é não apenas um grande desafio, mas uma necessidade se quisermos sair na frente da concorrência. Uma questão de sobrevivência.

Uma das maneiras mais conhecidas de escalar agilidade é o modelo proposto pelo Spotify em 2012, popularmente conhecido como “modelo em squads” e ele será o tema do artigo de hoje, caso ainda não conheça. O modelo completo e toda a cultura de engenharia do Spotify pode ser entendida no clássico vídeo abaixo (em Inglês):

Scrum é apenas o começo

O primeiro ponto a se entender, antes de partir para conceitos mais avançados, é que Scrum é apenas o começo. Isso assusta bastante no início e conheço vários agilistas que torcem o nariz quando ouvem isso. Como bem o Scrum Guide explica, o Scrum é cheio de lacunas e a maior de todas elas é a integração entre diferentes times trabalhando em um mesmo épico. Não é à toa que um dos criadores do Scrum, Ken Schwaber escreveu o Nexus, que é um exoesqueleto para o Scrum e outra alternativa para o modelo do Spotify.

Toda empresa que quer começar a praticar o gerenciamento ágil de projetos deve começar com Scrum na minha opinião, mas não deve permanecer nele (ou apenas nele) por muito tempo. Os próprios pilares de inspeção e adaptação conduzirão o time a algo maior que o próprio Scrum, e é assim que começa a história do Spotify de reestruturação do seu framework ágil.

Primeiramente, assim como já disse aqui no blog em outra ocasião, o que mais importa são os princípios da agilidade, mais do que qualquer framework. Embora exista o que é certo e errado perante o Scrum, não há as mesmas regras quando o assunto é o que funciona ou não na sua empresa.

Princípios acima de Processos

Queria começar estabelecendo alguns princípios que estão acima de qualquer processo ágil. Muitas vezes queremos copiar métodos de outras empresas sem percorrer o caminho que levou até aquelas conclusões. Essa busca por uma receita mágica de agilidade costuma levar a implementações flácidas e mecânicas baseadas em Scrum.

Mas agilidade não é Scrum.

Por trás do manifesto ágil, temos alguns princípios que são extremamente válidos de apontar para uma reflexão. São como mantras do gerenciamento ágil de projetos:

“Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de valor”.

Parece o propósito da Agiplan, mas não é. Este é o princípio mais importante dos métodos ágeis. Quando implantamos agilidade em uma empresa é porque queremos priorizar a satisfação do cliente. Ser ágil não é entregar mais software mais rápido, porque ninguém quer software, os clientes querem soluções.

“Aceitar mudanças de requisitos…para que o cliente possa tirar vantagens competitivas.”

Novamente, foco no cliente. Tenho lutado diariamente para criar uma cultura na equipe de canais digitais que promova a colaboração para construção de produtos ao invés de simplesmente entregar projetos. A diferença pode parecer sutil, mas não é.

“…negócios e desenvolvedores devem trabalhar em conjunto…”

Colaboração. Minha maior surpresa quando entrei na Agiplan foi descobrir que o time de produtos é um e o time de desenvolvimento é outro. Construí minha carreira trabalhando com startups e nesse tipo de empresa, quem faz o produto é o time de produto. Não apenas quem especifica ele em um documento, mas estamos trabalhando nisso.

“…indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão o seu trabalho.”

Ambiente, suporte e confiança. Aqui entram os líderes ágeis. Não importa o título que está no seu cartão de visita, se você não é a pessoa que está na linha de frente do projeto, você é a pessoa que deve garantir o ambiente, dar o suporte e confiar que o trabalho será bem feito.

E por fim

“As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.”

E eis que entramos em um ponto crucial, talvez o coração da agilidade: os times.

Times Ágeis em Escala

Na Agiplan estamos trabalhando para montar uma estrutura mais moderna de times ágeis, organizada em squads. Um squad é um grupo de até 8 profissionais multi-funcionais que possuem um objetivo em comum, como entregar o app de cartão múltiplo, ou fazer a arquitetura da nova abertura de contas. Para cumprir sua missão, eles devem ter autonomia para tomar decisões, ter todos os membros necessários com as habilidades necessárias e apoio dos seus líderes.

Toda squad deve ter no mínimo um Product Owner, que é o responsável da área de negócios que baliza o que está sendo feito naquela squad. Também deve ter um Scrum Master ou Agile Coach responsável por ajudar o time a melhorar sua eficiência, geralmente estes profissionais são compartilhados entre alguns squads dentro de uma mesma tribo, como Canais Digitais, por exemplo, onde temos os squads de Contas e Cartões, como já citado e que necessita de um líder da tribo que esteja olhando para os diferentes projetos.

Transversalmente aos squads, temos os chapters, que seriam os setores tradicionais como infra, mobile, web e UX. Estes setores ainda existem para garantir a evolução técnica do todo, compartilhamento de conhecimento da área, etc. Responsáveis pelos chapters geralmente são os líderes técnicos de cada área.

E transversalmente às tribos, temos as guilds ou comunidades, que são menos setorizadas que os chapters mas possuem objetivo semelhante e mais amplo (como garantir a cultura ágil em toda empresa ou a comunidade de estratégia corporativa). Um bom exemplo é o trabalho que o nosso Arquiteto Líder, Rubens Veronez, realiza de arquitetura de software nas diversas tribos da Agiplan.

Vantagens e diferenças do Modelo

Times autônomos, experientes e multifuncionais ganham copas. Possuem sentimento de dono, são mais motivados e geram inovação.

Times sem autonomia, que apenas seguem ordens, apenas fazem mais do mesmo. E se as empresas modernas quisessem apenas mais do mesmo, eu não estaria aqui hoje escrevendo sobre agilidade.

Os papéis não mudam muito em relação ao Scrum tradicional, apenas jogam um pouco mais de luz em áreas pouco explanadas. A evolução do conceito de Scrum Master para Agile Coach surgiu mais como uma necessidade de descolar este papel do framework Scrum em si, e mais tarde também trouxe uma conotação mais forte de coach e mentor agilista da organização. Os conceitos de agilidade são simples, difícil mesmo é ter a disciplina de aplicar diariamente.

O mesmo vale para as cerimônias, que temos as mesmas do Scrum com pequenas variações. A Sprint Review na Agiplan, por exemplo, que temos chamado de Demo Friday, mesmo quando ela não acontece nas sextas, está se tornando não apenas uma review, mas uma celebração das conquistas das equipes na última sprint, visando aumentar a motivação, o engajamento e aumentando a responsabilidade com a entrega, que é pública.

O restante segue como deve ser, com ênfase na Sprint Planning onde o time decide como que as tarefas serão realizadas e quanto tempo irá levar, desde que de acordo com a prioridade estabelecida pelo PO.

A cereja do bolo da agilidade, e talvez o maior desafio em termos de tecnologia para a Agiplan e diversas outras empresas é aplicar DevOps. DevOps tal qual definida pelos métodos ágeis nos levará a uma velocidade na entrega do valor sem precedentes, com o modelo self-service de deploy fortemente apoiada em contâiners e clusters.

Eu não sou a pessoa mais indicada para falar de DevOps para vocês mas presenciei isso acontecendo na última startup que trabalhei (Umbler) e é fenomenal.

Precisa-se de líderes

Nada disso pára em pé sem bons líderes que apoiem a causa. As squads precisam de suas missões e precisam de um ritmo. As squads mais competentes ainda precisarão de alinhamentos de quem tem uma visão mais ampla seja da tribo, do chapter ou da empresa inteira.

Somente um alto alinhamento permite que os times tenham autonomia sem isso aqui virar um caos completo. Mas para isso precisamos de confiança. Se hoje tem alguém no seu time que você não confia para dar autonomia, existe uma chance de você ter contratado a pessoa errada ou ela ainda não está pronta. De qualquer forma, você e somente você é o responsável por resolver isso.

Para encerrar, uma frase que eu gosto bastante do Mario Andretti, campeão mundial de fórmula um (e outras categorias do automobilismo) que diz o seguinte: se tudo parece sob controle, é porque você não está indo rápido o suficiente.

Na Agiplan obtivemos o apoio do presidente e do diretor de TI para fazer uma revolução completa na estrutura de pessoas e processos para torná-la mais ágil. Tem sido um trabalho árduo mas muito gratificante e já estamos colhendo alguns frutos como metas importantes sendo alcançadas, engajamento maior nos times, etc. Mas estamos apenas começando.

Quer continuar lendo sobre Agilidade em Escala Corporativa? Leia a segunda parte deste artigo.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!