Escalar o Ágil não ocorre apenas em processo e metodologia, mas também em cultura, gestão de produtos e serviços. Para isso, é necessário refletir em como escalar os valores e princípios do Manifesto Ágil nas organizações:

Valores do Manifesto Ágil

• Indivíduos e interações mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Princípios do Manifesto Ágil

1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
10. Simplicidade–a arte de maximizar a quantidade de trabalho não realizado–é essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como  se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Como percebemos, muitos dos valores e princípios são relacionados à cultura, e não métodos. Então escalamos ágil tanto em cultura, quanto em processos e produtos.

1. Atributos de Ágil em Escala

Quando diversas pessoas e times trabalham em conjunto, desenvolvendo diversas partes conectadas e integradas do produto final, é necessário realizar a gestão de dependências e sincronizar o trabalho de todos.

1.1 Gestão de Dependências

Este é um princípio importante de ágil em escala. Caso as dependências não sejam geridas pelo próprio processo ou pelas pessoas, muito desperdício haverá, tal como espera, retrabalho e estoque.

Existem diversas práticas de gestão de dependências. Uma delas é o Program Board utilizado pelo SAFe, o qual é criado na PI Planning (planejamento da iteração de programa) com todos os times, e mantido e atualizado ao longo das iterações. As dependências entre os times são mapeadas através das iterações (em vermelho na imagem a seguir).

Outra prática é do Spotify, definindo time a time quais tipos de dependências existem entre squads e tribos. Se a dependência é entre tribos, pode ser mais crítica, pois buscam dividir tribos para que não hajam dependências entre elas.

Em Kanban, a prática está em gerir as dependências com gestão visual, tornando o trabalho visível a todos num fluxo de trabalho representado num quadro. Para isso, divide-se os itens em Upstream e Downstream. Upstream representa a descoberta e priorização de itens, enquanto no Downstream o desenvolvimento de cada item puxado. No Kanban Maturity Model (KMM), essa prática de dividir o fluxo em Upstream e Downstream está no Nível de Maturidade ML3: Fit for Purpose, onde o fluxo de trabalho é escalado e adaptado ao que o cliente realmente necessita. Veja na imagem a seguir.

1.2 Sincronização

Para não haver espera e desperdícios relacionados a dependências, é necessária a sincronização do trabalho. Pode ser planejada em iterações, tal como no SAFe, ou realizada através de priorização em classes de serviço num fluxo contínuo de desenvolvimento, tal como em Kanban.

1.3 Pessoas

O ágil não escala sem a cultura ser disseminada entre as pessoas. De nada adiantará tendo processos e ferramentas ideais, se as pessoas não estiverem seguindo os valores e princípios ágeis.

O Spotify estabelece Guilds e Chapters para escalar ágil de uma forma orgânica tanto dentro das tribos, quanto entre tribos. Uma tribo é uma coleção de squads que trabalham em áreas relacionadas. Dentro das tribos, estabelecem Chapters (Capítulos) para troca de conhecimento especializado e focado na própria tribo. Já entre as tribos, as Guilds (Guildas) para troca de conhecimento organizacional e a nível de produto. Para escalar o ágil, estabelecem Chapters e Guilds de agilistas e agilidade.

2. Escalando Cultura

Escalar cultura está em levar os valores e princípios ágeis para as pessoas da organização. Existe uma grande diferença em fazer ágil e ser ágil. Fazer ágil é seguir processos, e ser ágil é agir e decidir conforme o manifesto ágil. A chave está em ser, além fazer ágil.

Para isso, pode-se estabelecer Agile Centers of Excellence (Agile CoEs), que é um grupo de especialistas em ágil na organização. Geralmente um grupo de agile coaches e agilistas. Na DBC, temos o DBC AGIL, um grupo de Agile Coaches, Scrum Masters e Agilistas com o objetivo de prover melhores serviços ágeis para clientes e projetos. Esse grupo possui uma liderança técnica de um Enterprise Agile Coach.

De uma forma mais orgânica, as Comunidades de Prática são grupos de especialistas ou interessados numa área do conhecimento, focados na mentoria e em troca de conhecimento sobre práticas e ferramentas. No Spotify também é chamado de Guilda (Guild). Na DBC, possuímos a CoP de Agilidade e a CoP de POs, as quais possuem encontros frequentes ou sob demanda própria do grupo.

Para engajamento das pessoas em maestria técnica e no aprender fazendo, a empresa pode patrocinar eventos organizacionais como Exploration Days, Hackathons ou ShipIt Days. Esses eventos podem ser organizados também a nível de times ou departamentos, o que torna mais acessível a realização. Exclusivamente para o time, Mob Programming é uma prática onde todos se reúnem e realizam uma tarefa por vez, gerando muito aprendizado e alinhamento com o trabalho ágil.

3. Escalando Produto

Ao escalar o ágil na organização, é necessário também pensar em formas e estratégias para escalar produtos em relação ao negócio e à qualidade interna do produto.

Para escalar o produto ao negócio, OKRs Objetivos e Resultados-Chave auxiliam a gerenciar metas flexíveis que engajem as pessoas que desenvolvem o produto. MVPs (Produto Mínimo Viável) podem ser desenvolvidos para testar o mercado e evoluir o produto, além coletar feedback dos usuários, numa visão de Lean Startup num ciclo de Construir, Medir, Aprender (Build, Measure, Learn).

Na organização do desenvolvimento de produto, é essencial ter um Backlog Único de Produto visível a todas as pessoas envolvidas. Também ter uma DoD (Definição de Pronto) Base para o produto, e então especializar essa DoD para cada time ou linhas de produto.

Na estruturação dos times e departamentos de produto, as tribos são divididas para desenvolver partes específicas do produto. Chapters auxiliam na melhoria do produto dentro de cada tribo.

Ao escalar um produto é preciso também investir na qualidade interna. “Você não pode escalar código malfeito” (“You can’t scale crappy code”). Essa frase do SAFe resume tudo. Práticas de eXtreme Programming (XP) e DevOps auxiliarão a construir um produto que suporte ser escalado. Diversas práticas de XP e DevOps tais como Design Emergente, YAGNI “You Ain’t Gonna Need It”, KISS “Keep It Simple, Stupid”, DRY “Don’t Repeat Yourself”, Posse Coletiva de Código, Padrão de Codificação, Revisão por Pares, Trabalho em Pares, Agile Testing, Automatização de Testes, Refatoração, Feature Toogles, Integração Contínua, Entrega Contínua, Deploy Contínuo, Monitoração, entre outras.

4. Escalando Processo

Ao escalar ágil na organização, é possível utilizar as estratégias de Gestão de Mudança Top-down ou Bottom-up, ou então de uma forma transversal que venho chamando de Processo Puxado. Top-down é quando a gestão da empresa demanda o ágil de uma forma diretiva (empurrada), através de uma decisão de cima para baixo na hierarquia da empresa. Bottom-up é quando um time inicia com métodos ágil, mostrando resultados e então escalando para outros times e departamentos.

Processo Puxado é um formato transversal onde as práticas ágeis vão sendo utilizadas e combinadas conforme demanda, através de um ciclo de melhoria contínua. Inicia-se com o mínimo de processo possível, e frequentemente vai se adaptando. Não necessariamente através de retrospectivas, mas através de um processo contínuo de melhoria de processo.

Não há um formato ideal de abordagem para escalar ágil na organização. Tudo depende da estratégia, do contexto, da cultura, além da urgência e do momento que se está.

Agile Fluency Model é um formato bottom-up, onde se inicia com a cultura ágil nos times. Posteriormente, segue-se para a melhoria da entrega dos times, para apenas depois então focar na otimização e fortalecimento da organização. Veja na imagem a seguir.

Nexus é framework do Scrum escalado. Segue os mesmos princípios do Scrum, porém para 3 a 9 times desenvolverem um produto único. Uma prática interessante nesse framework é que a reunião de Revisão da Sprint é realizada com todos os times, para reforçar a integração do produto. Algo que se deve estar atento ao utilizar o Nexus é que ele pode ter uma quantidade excessiva de reuniões. Em geral, Nexus é implantado top-down.

SAFe, Scaled Agile Framework, é um conjunto de práticas de ágil em escala para portfólio, soluções e sincronização de times. Muito mais que um framework, é um corpo de conhecimento (poderia se chamar de SABOK – Scaled Agile Body of Knowledge).  Em geral, SAFe é implantado top-down.

O Kanban Maturity Model (KMM) auxilia na avaliação e na evolução do processo, de nível em nível. Para escalar processos ágeis com Kanban, busca-se implementar o Nível de Maturidade ML3: Fit for Purpose, onde a organização possui um fluxo de valor focado no cliente através de classes de serviço, com processos de sincronização nas linhas de produto e serviços compartilhados. Veja na imagem a seguir os níveis de maturidade de Kanban.

Referências

Agile Fluency Model https://www.agilefluency.org/

Kanban Maturity Model https://www.kanbanmaturitymodel.com/

Manifesto para Desenvolvimento Ágil de Software https://agilemanifesto.org/iso/ptbr/manifesto.html

Nexus https://www.scrum.org/resources/nexus-guide

Scaled Agile Framework https://www.scaledagileframework.com/

Scaling Agile @ Spotify https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf