Um “pouco” mais sobre Scrum Escalado

Você acabou de implantar o Scrum na sua organização e já pensa em escalar o Scrum? Primeiro você precisa saber o que é a Escalada no Scrum. Vamos fazer nosso habitual alinhamento?

O que é Escalada do Scrum?

Escalar o Scrum é utilizar vários times Scrum para desenvolvimento de um único Produto. É diferente de você ter na sua organização vários times Scrum desenvolvendo vários Produtos.

Você precisará escalar no Scrum quando houver a necessidade de otimizar um sistema muito complexo, e o conceito de sistema complexo é que quanto maior a quantidade de linhas de código um sistema tenha, mais complexo ele será.

As principais características do Scrum Escalado são:

• Ter vários times Scrum multidisciplinar trabalhando no desenvolvimento de um único Produto;
• Se você está desenvolvendo um único produto, logo você terá apenas um Product Backlog, e claro, também terá apenas um Product Owner. Claro que ele pode ter outros membros para ajudá-lo, mas apenas ele terá autonomia para tomar as decisões, somente ele terá o poder de aceitar o concluído;
• Também teremos apenas uma definição de preparado (Ready), que precisa ser conhecida e aceita por todos os times;
• Todos os seus times Scrum vão construir apenas um incremento por Sprint, cada time não pode atuar em um incremento diferente do mesmo produto.

Para você estruturar o seu gerenciamento de projetos no modelo Scrum Escalado, existem vários frameworks que a sua organização pode adotar, veja alguns deles:

• SAFe: É o acrônimo de Scale Agile Framework, que foi desenvolvido por Dean Leffingwell. O SAFe uni a filosofia Lean com a abordagem Ágeis para gerir os múltiplos times, possui orientações em diversos níveis, como gerir equipe, programas e até mesmo o Portfólio de projetos;
• LeSS: que significa “Large Scale Scrum”, oferece 2 tipos de framework para escalada, o LeSS que é indicado para até 8 equipes, e o LeSS Huge, que é para equipes de mais de 1000 pessoas desenvolvendo um único produto. Mantém as práticas do Scrum, mudando apenas o formato de alguns eventos, como a daily;
• Nexus: a Scrum.Org criou um Framework chamado Nexus. Ele foi criado para te ajudar no desenvolvimento de produto por múltiplos times, inclusive existe uma certificação específica para utilizar o Scrum@Scale! Caso você queira informações mais detalhadas segue o link do Guia Nexus e a sobre a Certificação Scale Professional Scrum.

Amaioria das empresas quando tentam realizar uma adoção ágil, normalmente, costumam encontrar dois cenários. No primeiro, a adoção começa a ser disseminada em uma única equipe/área e depois se espalha por toda a empresa. Esse cenário é ótimo, faz com que as pessoas se motivem, atribuam mais empenho em seus trabalhos e, dessa forma, evoluam. No segundo cenário algumas coisas mudam, o Agile começa a ser disseminado em uma única equipe/área, porém, acaba se restringindo somente a ela. A equipe/área acaba não tendo apoio de outras equipes/áreas, isso pela forte estrutura hierárquica que comanda e engessa a empresa. Se você encontrou uma similaridade no segundo cenário, sugiro que continue comigo. 🙂

Como funciona o SAFe?

SAFe é um acrônimo para Scaled Agile Framework, ele foi criado por Dean Leffingwell e hoje é mantido pela Scaled Agile Academy, sua estrutura baseada em princípios Lean e Agile, está ganhando cada vez mais reconhecimento e adoção por todo mundo. O SAFe leva como base o Scrum, XP (Extreme Programming) e o Lean, além de muita experiência obtida através de implementações que funcionaram e não funcionaram em grande escala. O SAFe traz consigo o que melhor tem funcionado em equipes ágeis, na maneira de fazer gestão de programa e na maneira ágil de tratar um portfólio de demandas organizacionais.

O que o Agile e o Scrum são para as equipes, o SAFe (Scaled Agile Framework) é para as empresas.

SAFe é uma abordagem comprovada e bem documentada para trazer Agile e seus benefícios para a empresa em geral. Ele fornece uma visão abrangente dos princípios e práticas de negócios e técnicos necessários de cima para baixo da empresa para escalar com sucesso Agile. Esses princípios e práticas não são todos inteiramente novos ou exclusivos do SAFe, mas foram puxados juntos em um pacote coeso pronto para implantação.

O SAFe fornece uma estrutura que se entende muito bem com o nível estratégico, nível tático e também com o nível operacional. Para melhor entender a sua aplicação em cada um desses níveis organizacionais, o SAFe fornece um conjunto de práticas para:

• Equipe (Team): O nível de Equipe fornece um modelo de processo para equipes ágeis baseadas em Scrum e práticas do XP.

• Programa (Program): Ao nível do programa, os esforços de várias equipes ágeis são integrados para fornecer lançamentos de maior valor para a empresa.

• Portfólio: No nível Portfólio, os programas estão alinhados à estratégia de negócios e de intenções de investimento.

Razões para usar SAFe

1. Experimentou-se o Agile em nível de equipe, tendo bons resultados (cases de sucesso) e agora quer expandir a abordagem Agile em mais equipes/áreas;
2. Tem múltiplas equipes que executam suas próprias implementações Agile, mas sofrem quando o planejamento envolve mais equipes ou pela falta de sincronização;
3. Sua organização quer escalar Agile, mas não sabe quais funções podem ser necessárias ou quais existentes;
4. Tentaram escalar Agile na sua organização, mas há dificuldades em alcançar uma estratégia consistente em todos os departamentos de negócio;
5. A sua organização precisa melhorar os lead times de desenvolvimento de produto, já ouviu falar sobre o sucesso que empresas experimentaram ao escalar Agile com o SAFe e quer saber como eles fizeram isso.

Como funciona o LeSS?

O LeSS começa com a compreensão do Scrum padrão de uma equipe. A partir desse ponto, sua organização deve ser capaz de compreender e adotar este framework, o que requer examinar o propósito dos elementos Scrum de uma equipe e descobrir como alcançar o mesmo propósito enquanto permanece dentro das restrições das regras Scrum padrão.

O desenvolvimento ágil com Scrum requer uma profunda mudança organizacional para se tornar ágil. Portanto, nem Scrum nem LeSS devem ser considerados meramente uma prática. Em vez disso, eles formam uma estrutura de design organizacional.

Dois frames de escala diferentes

O LeSS fornece dois frameworks Scrum de grande escala diferentes. A maioria dos elementos de dimensionamento se concentram em direcionar a atenção de todas as equipes para o produto inteiro, em vez de “minha parte”. O foco global e “ponta a ponta” são talvez os problemas dominantes a serem resolvidos no dimensionamento. Os dois frameworks – que são basicamente Scrum de equipe única ampliada – são:

• LeSS: Até oito equipes (de oito pessoas cada)
• LeSS Huge: Até alguns milhares de pessoas em um produto

Em suma, o LeSS é uma versão ampliada do Scrum de uma equipe e mantém muitas das práticas e ideias do Scrum de uma equipe. No LeSS, você encontrará:

• Um único Product Backlog (porque é para um produto, não uma equipe),
• Uma definição de Pronto para todas as equipes,
• Um incremento de produto potencialmente comutável no final de cada Sprint,
• Um proprietário do produto,
• Muitas equipes multifuncionais completas (sem equipes de um único especialista),
• Um Sprint.

No LeSS, todas as equipes estão em um Sprint comum para entregar um produto distribuível comum.

O que é diferente no LeSS?

• Sprint Planning Part 1: Além de um Product Owner, inclui pessoas de todas as equipes. Os membros da equipe administram sua divisão de itens do backlog do produto e também discutem oportunidades para encontrar trabalho compartilhado e cooperar, especialmente para itens relacionados.
• Sprint Planning Part 2: Este é realizado de forma independente (e geralmente em paralelo) por cada equipe, embora às vezes para coordenação simples e aprendizagem, duas ou mais equipes podem realizá-lo na mesma sala (em áreas diferentes).
• Daily Scrum : Também é realizado independentemente por cada Time, embora um membro do Time A possa observar o Daily Scrum do Time B, para aumentar o compartilhamento de informações.
• PBR geral : Pode haver uma reunião geral opcional e curta de Refinamento do Backlog do produto (PBR) que inclua um PO e pessoas de todas as equipes. O objetivo principal é decidir quais equipes têm probabilidade de implementar quais itens e, portanto, selecionar esses itens para PBR de equipe única aprofundado posteriormente. É também uma oportunidade de aumentar o alinhamento com o Product Owner e todas as equipes.
• Refinamento do Backlog do Produto : O único requisito no LeSS é o PBR de equipe única, o mesmo que no Scrum de uma equipe. Mas uma variação comum e útil é o PBR de várias equipes, onde duas ou mais equipes estão na mesma sala juntas, para aumentar o aprendizado e a coordenação.
• Revisão do Sprint : Além de um Product Owner, inclui pessoas de todas as equipes, clientes / usuários relevantes e outras partes interessadas. Para a fase de inspeção do incremento de produto e novos itens, considere um estilo “bazar” ou “feira de ciências”: uma grande sala com várias áreas, cada uma com membros da equipe, onde os itens desenvolvidos pelas equipes são mostrados e discutidos.
• Retrospectiva geral : Esta é uma nova reunião não encontrada no Scrum de uma equipe, e seu objetivo é explorar a melhoria do sistema geral, ao invés de focar em uma equipe. A duração máxima é de 45 minutos por semana de Sprint. Inclui o Product Owner, Scrum Masters e representantes rotativos de cada Equipe.

Como funciona o Nexus?

A definição de Nexus que você pode encontrar no Guia Nexus é: ”um relacionamento ou conexão entre pessoas ou coisas. “.

Portanto, o Framework Nexus é constituído de papéis, eventos, artefatos e regras que os unem e entrelaçam junto o trabalho de aproximadamente três a nove Times Scrum em um único Backlog do Produto para construir um incremento integrado que alcance uma meta.

Quando falamos sobre integração de times, você precisa ter organização e coordenar todos os times para entregar apenas um incremento por Sprint, sem falar que você precisará resolver todos os impedimentos e não criar dependências entre os times.

Para que essa integração seja possível, foi criado o Time de Integração do Nexus, que possui os seguintes papeis:

• Um Product Owner
• Um Scrum Master
• Um ou mais Membros do Time de Integração Nexus.

Como o Nexus agrupa vários times Scrum para desenvolver um único produto, cada um dos seus times irá trabalhar conforme indicado pelo framework Scrum, exceto a Sprint Review que será substituída pela Sprint Review do Nexus, exemplificado no fluxo abaixo.

Já o fluxo de trabalho no Framework Nexus é diferente, pois entra novos papeis e novos artefatos. Também fez surgir novos eventos, e alguns foram remodelados como mostra o fluxo abaixo:

Agora que você já conhece o que é e como funciona a escalada do Scrum, você terá um briefing das diferenças entre os papéis, artefatos e eventos.

• Time de Integração: Que é composto pelo PO, Scrum Master e membros dos demais times Scrum, deve coordenar e orientar a aplicação Nexus para garantir os melhores resultados. Como o Product Backlog é único, o PO também deve ser único, e apenas o time de integração tem autoridade para aceitar o produto como concluído. O Scrum Master do time de integração pode atuar em outros times que compõe o time Nexus.
• Sprint Planning Nexus: É um novo evento que irá gerar o novo artefato que é o “Backlog da Sprint Nexus”, nesse evento participa o time de Integração Nexus e um representante de cada time Scrum participante do time Nexus.
• Backlog Sprint Nexus: Neste artefato contém todos os itens que serão desenvolvidos na Sprint bem como a indicação de qual time irá desenvolvê-lo. Cada um dos times deverá ter o seu Backlog da Sprint individualmente.
• Scrum of Scrums: Nos times Scrum temos as “Daily”, que continuam acontecendo normalmente, porém, assim que terminar, um representante de cada time (normalmente o Scrum Master) participa de uma reunião chamada Scrum of Scrum, que é um espelho da daily dos times, onde todos falam dos seus impedimentos, e se faz a comunicação fluir para todos os times do Nexus.
• Sprint Review do Nexus: Como o time Nexus está desenvolvendo um único incremento para um único produto, a Sprint Review do Nexus substituirá as Sprint Review individual dos times Scrum.
• Sprint Retrospectiva Nexus: Esse evento também passa englobar a Sprint retrospectiva de cada time, e também juntos vão encontrar a melhor maneira de trabalho para o Time Nexus.

Neste artigo, o principal objetivo foi demonstrar de forma resumida um pouquinho do que é o Ágil Escalado. Quer saber mais sobre estes frames de escala? Comenta aqui embaixo, qual você gostaria de saber um pouco mais no detalhe?