Introdução ao Scrum em Larga Escala (LeSS)

Large Scale Scrum, LeSS para abreviar, chamou sua atenção. Talvez você tenha acabado de começar com Scrum, mas já está pensando nos próximos passos.

Talvez você seja um veterano de Scrum de equipe única, procurando expandi-lo para outras equipes.

Img Src: less.works

Ou talvez você já tenha várias equipes seguindo Scrum e esteja passando por alguns dos desafios de coordenar várias equipes trabalhando em um único produto.

De qualquer forma, você quer saber mais sobre o Scrum em Larga Escala para ver se ele é adequado para você.

Bem, você está no lugar certo.

Neste artigo, você terá uma visão geral abrangente, mas sucinta do LeSS para que possa tomar uma decisão informada sem se perder em todos os detalhes.

Visão Geral Resumida

Large Scale Scrum, LeSS para abreviar, é um framework Agile em escala que o orienta na adoção e aplicação Agile em escala.

O LeSS mantém intacto o núcleo do Scrum: expondo as fraquezas do projeto organizacional através de um framework mínimo e deixando-o resolver os problemas complexos inerentes ao desenvolvimento, através do controle empírico do processo e da melhoria contínua.

O LeSS procura aplicar os “princípios, propósito, elementos e elegância do Scrum em um contexto de grande escala, da maneira mais simples possível”. Entre outros princípios e práticas, utiliza o Pensamento Lean e Pensamento de Sistemas para manter o framework e suas despesas gerais tão leves quanto possível e ainda guiá-lo em decisões importantes.

Na verdade, o Scrum em Larga Escala define dois frameworks:

• O LeSS permite escalar o Scrum para até oito equipes de até oito pessoas cada.

• O LeSS Huge ajuda você a escalar Scrum até algumas milhares de pessoas em um único produto.

Ao escolher aquele que se encaixa no seu tamanho, você não vai se sobrecarregar com lastro desnecessário.

Para clarificar qualquer confusão: a palavra LeSS significa tanto Large Scale Scrum em geral como o framework para organizações menores.

Breve História

Em 2005, Craig Larman e Bas Vodde criaram o Large Scale Scrum trabalhando em conjunto na Nokia Siemens Networks aplicando Agile e Scrum ao desenvolvimento de produtos muito grandes e de múltiplos locais.

Desde então, grupos de produtos aplicando LeSS executam a gama em escala, desde pequenas como duas equipes até grandes como 2500 pessoas.

Princípios e Práticas

O LeSS, mais do que qualquer outro framework ágil em escala, trata de seguir o Scrum e fazer com que você tome suas próprias decisões guiado pelos princípios e práticas que também guiaram Craig Larman e Bas Vodde durante sua criação.

Aplicar o LeSS significa:

• Esclarecer sobre as poucas regras que considera obrigatórias.

• Seguir a orientação de seus 10 Princípios na tomada de suas decisões.

• Estruturar seu grupo de produtos de acordo com sua descrição de como se organizar.

• Seguir sua descrição de Scrum Sprints em um contexto de grande escala.

• Aplicar as práticas que ela define para Excelência Técnica.

• Levar a sério o que tem a dizer sobre a adoção bem sucedida do LeSS.

• Levar em conta o que tem a dizer sobre coordenação e gestão em uma nova realidade.

Regras

O LeSS tem apenas algumas regras, mas elas são cruciais. Elas especificam o que o LeSS considera um dever para sua estrutura organizacional, gerenciamento de produtos e como trabalhar com várias equipes em um único Sprint de nível de produto.

Img Src: less.works

Para tudo mais, você é livre para tomar suas próprias decisões guiado pelos mesmos princípios que guiaram os autores do LeSS em sua criação.

Eu não vou repetir as Regras do LeSS aqui, mas defendo mantê-las sempre à frente e no centro para que possam ser consultadas com frequência (são apenas duas páginas!).

Princípios

O LeSS pode ser enxuto em regras por causa de seus dez princípios para orientar suas decisões por tudo o que não considera essencial.

Img Src: less.works

• Scrum em Larga Escala é Scrum
• Mais com LeSS
• Pensamento de Sistemas
• Pensamento Lean
• Controle de Processos Empírico
• Transparência
• Melhoria Contínua Rumo à Perfeição
• Centrado no Cliente
• Foco no Produto Inteiro
• Teoria de Fila

Princípio 1: Scrum em Larga Escala é Scrum

O LeSS escalona o próprio Scrum sem adicionar diferentes processos de escalonamento, artefatos ou eventos.

Princípio 2: Mais com LeSS

O LeSS ajuda você a simplificar gradualmente sua organização e confiar na responsabilidade, propriedade e centralidade no cliente, em vez de papéis, processos e artefatos.

Princípio 3: Pensamento de Sistemas

O pensamento de sistemas ajuda a todos em sua organização (não apenas no desenvolvimento de produtos) a pensar sobre o que está acontecendo e ajuda os tomadores de decisão a evitar erros de “senso comum” e “correções rápidas”.

Princípio 4: Pensamento Lean

Uma boa analogia para o Pensamento Lean é “Observe o bastão, não os corredores” [em uma corrida de revezamento].

Isso significa que não se busca melhorias de produtividade na utilização de recursos (ocupação), mas na remoção de desperdícios (material e tempo de trabalho/liberdade) do processo de produção. Em outras palavras: acelerar o bastão.

Princípio 5: Controle de Processos Empírico

Img Src: volkerdon.com

O controle empírico do processo ajuda você a “falhar para frente”, fazendo com que você produza incrementos de trabalho de seu produto em ciclos curtos, e a adaptar o produto e a maneira como você o cria, inspecionando-os a cada ciclo.

Princípio 6: Transparência

A transparência ajuda você a resolver os pontos fracos dos processos, ferramentas, técnicas, ambientes, locais, políticas, pessoas, grupos, sistemas de recompensa, etc., em toda a sua organização.

Princípio 7: Melhoria Contínua Rumo à Perfeição

A melhoria contínua rumo à perfeição diz três coisas:

• “Não há problema em não ser perfeito agora”.
• “No entanto, você quer e precisa se esforçar continuamente para chegar lá”.
• “Você precisa aceitar nunca chegar lá porque sempre haverá algo mais para melhorar”.

Princípio 8: Centrado no Cliente

No LeSS, o objetivo é escalar e ainda manter o foco do cliente em toda a organização para que as equipes no piso não acabem divorciadas do valor que seu trabalho proporciona aos clientes.

Princípio 9: Foco no Produto Inteiro

O LeSS defende manter todas as equipes concentradas no produto inteiro, não apenas em sua pequena parte.

Princípio 10: Teoria de Fila

A teoria das filas ajuda a melhorar o fluxo de trabalho através de seus processos de desenvolvimento e portfólio com orientações sobre como eliminar filas e gerenciar as que não podem ser eliminadas.

Filas e inventários não existem apenas na fabricação física, elas também estão presentes no desenvolvimento de produtos.

Por exemplo:

• O portfólio de projetos e produtos é uma fila de espera.
• O backlog do produto é uma fila de espera.
• O backlog do Sprint é uma fila de espera.
• Cada status em um fluxo de trabalho é uma fila onde o trabalho espera para ser retomado para o próximo passo.
• Um servidor de integração sobrecarregado é uma fila de espera.
• Ambientes de teste compartilhados são filas de espera.

E também há muito inventário nessas filas.

• Documentos de design acabados à espera de serem implementados.
• Qualquer código ainda não liberado, ou mantido dos clientes por bandeiras de funcionalidades, em vários estágios de conclusão.
• Os branches de funcionalidades são tanto um inventário quanto uma fila de espera.

Práticas

Img Src: less.works

A verdadeira flexibilidade (ou seja, agilidade) só acontece quando você pode fazer mudanças em seu produto de forma rápida, fácil e flexível. Isso significa excelência técnica para a qual o LeSS nomeia 10 práticas de engenharia e design:

1. Integração contínua
2. Entrega contínua
3. Arquitetura e Design
4. Código limpo
5. Testes unitários
6. Desenvolvimento orientado a testes (TDD)
7. Pensando em testes
8. Automação de testes
9. Testes de aceitação
10. Especificação pelo exemplo

Todas estas práticas estão interligadas, dependem umas das outras e se amplificam mutuamente.

Você pode ler mais sobre integração contínua, entrega e implantação e sua relação com testes unitários, automação de testes e testes de aceitação automatizados  em O que é CI/CD? Como isso ajuda as equipes a entregar um software melhor, mais rápido.

Ao invés de uma grande arquitetura e projeto inicial, Agile e LeSS têm uma abordagem evolutiva, isto requer todas as outras práticas para manter o código fácil de ser alterado e as equipes confiantes em mudar a arquitetura e o projeto do código sem afetar o funcionamento.

A especificação por exemplo, como usada em histórias de usuários ou através do Desenvolvimento Comportamental, facilita as especificações que um computador pode executar que tornam a automação de testes viável em todos os níveis, incluindo testes de aceitação.

Similitudes e Diferenças

LeSS versus Scrum de equipe única

Em vez de usar Scrum em nível de equipe e aplicar diferentes métodos para planejar, coordenar e aprender com várias equipes, o próprio LeSS escalona o Scrum e mantém seu núcleo intacto.

Mas há diferenças.

Aquelas que o próprio LeSS relata:

• As equipes do LeSS são o que Scrum vê como a equipe de desenvolvimento. A equipe Scrum não é um conceito no LeSS.

• O LeSS fala sobre autogestão em vez de equipes auto-organizadas.

• O LeSS vê o papel do Scrum Master como um trabalho dedicado em tempo integral. Entretanto, um Scrum Master pode orientar e treinar até três equipes para ver o produto maior e o sistema de produção.

• O LeSS não exige que o proprietário do produto participe do Scrum Diário ou Retrospectivo de cada equipe.

• O LeSS divide o Planejamento de Sprint em duas partes.

• O LeSS espera que o Refinamento do Backlog seja um evento formal (é uma atividade no Scrum).

• O LeSS não requer Sprints para ter um Objetivo Sprint, embora o considere uma prática útil.

Além disso:

• O Product Owner não é obrigado a participar do Refinamento do Backlog de Produtos de cada equipe. As equipes conduzem o refinamento com clientes e usuários, liberando o Product Owner para fazer um trabalho mais prospectivo.
• O LeSS acrescenta uma Retrospectiva geral para todas as equipes juntas.

• O LeSS aborda especificamente o papel que os gerentes ainda podem desempenhar e como eles ainda podem agregar valor mesmo quando suas responsabilidades são amplamente assumidas pelo Product Owner ou delegadas às Equipes.
• Onde o Scrum diz três a nove em uma equipe ou equipe de equipes, o LeSS recomenda um máximo de oito. É baseado em observações durante muitas adoções do LeSS.

Planejamento e Orçamento

O LeSS se mantém com os ciclos de planejamento Scrum por impressão. Não há ciclos de planejamento global ou eventos como o planejamento trimestral de PI em SAFe.

O foco total do produto LeSS e a ênfase em equipes de recursos estáveis de longa duração, significa que uma abordagem orientada ao produto é um ajuste natural para planejamento e orçamento. O custo por ano decorre do número e tamanho das Equipes de Destaques e do tamanho da equipe do Product Owner.

A questão que permanece é quando as correções específicas e atualizações de recursos estarão disponíveis.

Isto pode ser tirado, na verdadeira forma Scrum, da priorização do Backlog de Produtos e de sua experiência com o quanto as equipes podem lidar em um Sprint.

Coordenação

LeSS e LeSS Huge evitam ambos a ritualização da coordenação entre as equipes em eventos.

LeSS declara explicitamente: “Coordenação: Basta Conversar, Comunicar em Código, Viajantes, Espaço Aberto e Comunidades”.

Em outras palavras:

• Colaboração entre equipes, conforme necessário, em arquitetura, design, modelagem, etc.
• Use o código fonte como fonte de conhecimento sobre o produto.
• Use “tecnologia” Open Space para compartilhar informações, conhecimentos e experiências.
• Promova interações entre as equipes através da observação dos Scrums Diários um do outro e simplesmente sentados tendo um ou mais membros sentados com outra equipe (Viajantes).
• Forme Comunidades de Prática (CoP) auto-organizadas de voluntários com um interesse compartilhado. Apoie os líderes informais, coordenadores de CoP, que naturalmente sobem no grupo por causa de seu interesse mais do que médio no tópico.
• Use CoPs para disseminar o conhecimento através de suas Equipes de Funcionalidades Cruzadas. Elas têm o mesmo objetivo que o antigo sistema de matriz, mas sua abordagem é fundamentalmente diferente.

Teoria de Filas

LeSS é o único framework ágil em escala que aceita explicitamente todas as implicações da teoria das filas e a defende para orientar suas decisões de melhoria.

Isso significa eliminar filas, não apenas gerenciá-las através do gerenciamento dos níveis do Em Andamento (WIP).

O LeSS valoriza a redução dos níveis de WIP por muitas razões, mas chama a invocação da Lei de Little para dizer que ela leva automaticamente a uma redução nos tempos de ciclo, um mito. Isto porque a prova na Lei de Little, como afirma o LeSS: “depende de condições e suposições que não são de forma alguma garantidas ou mesmo comumente verdadeiras em domínios de alta variabilidade, como software”. Isto é certamente verdade quando medido em períodos de tempo relativamente curtos (ou matematicamente) finitos.

Principais Papéis e Responsabilidades

Em uma organização LeSS não há lugar para gerentes de projetos ou um escritório de gerenciamento de programas/projetos (PMO). Você não precisa deles porque suas responsabilidades são transferidas para um Product Owner e para as equipes de recursos, e para evitar confusão e até mesmo possíveis guerras de território.

Em uma organização LeSS, as Equipes de Funcionalidades fazem o trabalho de desenvolvimento.

Elas são o que outros chamariam de equipes de produto. Cada equipe cria e é responsável pelas funcionalidades centradas no cliente de ponta a ponta, em vez de componentes ou uma camada técnica. Elas permanecem juntas por um longo período de tempo. Elas são autogeridas e multifuncionais — agrupados, seus membros têm todas as habilidades de que precisam para produzir um incremento entregável.

Eles são guiados e treinados por um Scrum Master. No LeSS, este é um trabalho dedicado, em tempo integral, embora um Scrum Master possa servir até três equipes.

Todas as equipes de funcionalidades têm o mesmo Product Owner e compartilham um único Backlog do Produto.

O Product Owner pode ter uma equipe do Product Owner na qual outros Gerentes de Produto deem suporte ao Product Owner. Juntos, eles são frequentemente chamados de Gerenciamento de Produto.

O Product Owner (Equipe) conecta clientes/usuários e equipes para que as equipes possam fazer o refinamento detalhado do backlog diretamente com eles. Como o Product Owner não precisa atuar como intermediário neste processo, ele pode se concentrar na descoberta do produto junto aos clientes.

Observe que no LeSS o Proprietário do Produto e as Equipes de Recursos são pares. O LeSS, assim como o Scrum, procura explicitamente manter um equilíbrio de poder entre eles.

LeSS Huge

O LeSS Huge agrupa as Equipes de Funcionalidades em Áreas de Requisitos de Produtos — principais áreas de requisitos do cliente em oposição às camadas do sistema ou subsistemas de arquitetura.

Ele introduz uma Área de Product Owner (APO) na Equipe do Product Owner, com cada APO focando em uma única área de requisitos de produto.

Cada item no Backlog do Produto é atribuído a uma única Área de Requisitos do Produto. O Backlog da Área é então simplesmente um filtro no Backlog completo.

Estrutura Organizacional

Muitas organizações que fizeram a transição para o LeSS ainda têm gerentes. O LeSS é um dos poucos frameworks que aborda especificamente como eles podem se reinventar e fornecer valor, apesar de perderem muitas de suas responsabilidades tradicionais.

Img Src: less.works

O Chefe do Grupo de Produtos é o gerente hierárquico de todas as equipes que trabalham com o produto. Ele apóia as equipes de recursos, ajudando-as a superar obstáculos e a adquirir e melhorar suas habilidades.

O Departamento Undone não é um departamento real, e sim um nome fantasma de departamentos tradicionais como Análise de Negócios, QA e testes e Arquitetura. Não há lugar para eles no LeSS e você irá desmontá-los à medida que for avançando na adoção do LeSS. Seu pessoal será então transferido para se tornar membro das equipes de funcionalidades.

LeSS Huge

Em vez de usar áreas de exigência de produtos para estrutura organizacional, o LeSS Huge propõe que você estruture sua organização por local. Isto mantém a organização de sua linha local intacta e ajuda a permanecer flexível e adaptável em quais áreas de exigência você quer ou precisa (não há necessidade de mudar sua organização quando você muda as áreas de exigência).

Enquanto você estará desmontando os departamentos que compõem o Departamento Undone, em grandes organizações ainda compensa ter um grupo de suporte para gerenciar e administrar o ambiente de desenvolvimento. Mantenha-o pequeno e concentre-o em como eles podem ajudar as equipes em vez de prescrever o que as equipes podem e não podem usar.

O LeSS considera o treinamento crítico para o sucesso de sua transição. No LeSS Huge, ele recebe seu próprio departamento de Competência e Coaching focado na melhoria contínua através de observação, treinamento e coaching

Principais Reuniões, Ciclos e Cadências de Entrega

Uma Sprint no LeSS é quase idêntica ao Sprint do Scrum de uma única equipe.

Img Src: less.works

Todas as equipes começam e terminam o Sprint ao mesmo tempo.

Todas as equipes trabalham a partir de um único Backlog do Produto.

Todas as equipes utilizam a mesma Definição de Feito.

Todas as equipes trabalham para um único Incremento de Produto Potencialmente Expansível.

Planejamento de Sprint

Um Sprint começa com o Planejamento do Sprint para todas as equipes ao mesmo tempo.

É dividido em duas partes.

1. Planejamento de Sprint Um

O Product Owner e o(s) representante(s) de todas as equipes decidem em quais itens cada equipe trabalhará e discutem quaisquer questões em aberto que não foram resolvidas durante o Refinamento do Backlog. Além disso, as equipes identificam o que, se houver, é necessário para a coordenação.

Note que o LeSS diz explicitamente que o Scrum Master não deve ser o representante de uma equipe. Sendo um trabalho dedicado no LeSS, o Scrum Master tem um conjunto de habilidades e conhecimentos completamente diferente do que alguém em quem uma equipe confia para fazer julgamentos sobre o impacto da carga de trabalho e as dependências dos itens de trabalho.

2. Planejamento de Sprint Dois

Isto é quase sempre o mesmo que no Scrum de equipe única. As equipes planejam seu Sprint em detalhes, decidindo como eles conseguirão finalizar seus itens. Quando as equipes trabalharem em itens similares ou relacionados, elas poderão fazer seu planejamento Sprint no mesmo local para que possam planejar os itens juntos e se comunicar facilmente sobre trabalho compartilhado e oportunidades de colaboração, pois de outra forma planejam seu Sprint por equipe.

Scrum Diário

Cada equipe conduz seus próprios Scrums Diários. Eles não precisam estar ao mesmo tempo. Isso facilita a recepção de observadores de outras equipes para troca de informações e conhecimentos.

Refinamento do Backlog do Produto (PBR)

Durante o Sprint, as equipes realizam suas próprias reuniões com clientes e usuários — mas não com o Product Owner, para refinar itens sobre o backlog do produto que provavelmente serão trabalhados no(s) próximo(s) Sprint(s). Estas reuniões não precisam ocorrer ao mesmo tempo, mas as equipes podem decidir refinar itens similares e relacionados juntos.

Opcionalmente, as equipes podem conduzir um PBR Geral que inclui o Product Owner para decidir qual equipe provavelmente trabalhará em quais itens.

Revisão de Sprint

A Revisão de Sprint no LeSS é uma reunião de todas as equipes, incluindo o proprietário do produto, clientes e usuários, e outras pessoas com uma participação no produto ou no incremento.

Retrospectiva

Assim como o Planejamento de Sprint, a Retrospectiva é dividida em duas partes.

Primeiro, cada equipe conduz sua retrospectiva específica como fariam no Scrum de equipe única.

Em seguida, é feita uma Retrospectiva Geral com a participação do Product Owner, do(s) Scrum Master(s) das equipes e dos representantes rotativos de cada equipe. Esta segunda parte se concentra em como todas as equipes estão trabalhando juntas em um único sistema de desenvolvimento.

LeSS Huge

Não há eventos extras (reuniões). O Product Owner e os Product Owners de Área são a cola entre todas as equipes.

Img Src: less.works

O LeSS Huge é a execução paralela de LeSS Sprints por todas as áreas de requisitos.

Métodos e Técnicas

Além das práticas de excelência técnica, o LeSS não prescreve nenhum método ou técnica.

Armadilhas Comuns

O LeSS possui as mesmas armadilhas que o Scrum e como qualquer adoção Agile em múltiplas equipes.

As maiores armadilhas específicas do LeSS são:

• Não adotar a colaboração entre equipes em arquitetura, design e modelagem e, portanto, não tornar as opções e soluções conhecidas e disponíveis em todas as equipes.
• Não se esforçar para desmantelar os departamentos desfeitos e manter os gerentes de projetos e um Escritório de Gerenciamento de Projetos por perto, reduzindo assim a clareza e a probabilidade de enfrentar guerras de território e improdutivas, pois ninguém gosta de perder partes de seu reino.
• Não romper o relacionamento de relatórios entre os membros da equipe multifuncional com seus antigos gerentes e, assim, colocá-los em uma situação de lealdade conflitante.

Começando

O LeSS é uma das poucas abordagens de escalonamento Agile que fala explicitamente sobre os princípios, desafios e partes e práticas essenciais para a adoção do LeSS e do LeSS Huge. Portanto, aproveite isso quando iniciar sua adoção do LeSS.

Img Src: less.works

Alguns princípios básicos a serem colocados em prática para uma adoção mais bem-sucedida:

• Coloque todos na mesma página em seu conhecimento e compreensão de Scrum e LeSS. Invista em vários dias de treinamento para todos.

• Coloque todos na mesma página sobre o produto por inteiro em que todos estão trabalhando.

• Use uma forte Definição de Feito (ao invés de uma definição fraca que reflita a realidade atual) e crie equipes interfuncionais que possam atendê-las movendo pessoas (deixando-as voluntariamente!) de Departamentos Undone para dentro delas.

• Deixe claro que somente o Product Owner pode dar trabalho às equipes. Você não quer que nenhuma equipe seja interrompida e sente qualquer obrigação de atender a pedidos aparentemente razoáveis do gerente de linha, Vendas, RH, ou mesmo do CEO.

• Os gerentes de projeto não têm nenhum papel no LeSS, mas podem ainda estar por perto enquanto você coloca as coisas em ordem. Durante esse tempo, mantenha-os o mais distantes possível das equipes, pois é provável que eles interrompam e causem confusão sobre se os membros da equipe ainda devem agir de acordo com o que eles dizem. Veja o ponto anterior.

Leitura Adicional

Craig Larman e Bas Vodde — os autores de Large Scale Scrum — escreveram três livros sobre LeSS e sua experiência trabalhando com clientes para aplicar LeSS para escalar o Scrum.

• Scaling Lean and Agile Development (2009)
• Practices for Scaling Lean and Agile Development (2010)
• Large-Scale Scrum: More with LeSS (2015)

Os capítulos destes livros estão disponíveis online:

• Introduction to LeSS (Capítulo 2 do livro de LeSS) — onde você pode encontrar muitos detalhes sobre os tópicos discutidos (e não discutidos) neste artigo.
• Inspect & Adapt Chapter de “Practices for Scaling”
• Agile Contracts
• Design and Architecture
• Lean Thinking
• Feature Teams

A Agile Alliance tem um artigo muito interessante sobre o LeSS sem Scrum. Ele fala de uma abordagem para adotar primeiro o projeto da organização do LeSS e só depois introduzir o Scrum.

Você Está Pronto Para Fazer Mais Com o LeSS?

Se você adere à ideia de “Menos é mais” e quer manter as despesas gerais a um mínimo.

Se você valoriza manter todos focados no produto por inteiro o tempo todo.

Se você se sente confortável com a realização de experimentos e com a adaptação à medida que avança.

Se você gosta que as equipes progridam em sua adoção do Scrum em seu próprio ritmo.

Então você está pronto para adotar o Scrum em Larga Escala como seu framework de escalonamento Agile.

Seu primeiro passo para isso seria aprender mais sobre o LeSS, especialmente seus princípios fundamentais e seus princípios para adotá-lo.

Eu recomendo fazê-lo coletivamente usando as mesmas fontes ou treinadores. Isso garante que todos os envolvidos comecem com o mesmo nível de conhecimento e compreensão, o que irá melhorar as conversas em torno de sua adoção.

Se você não estiver pronto para adotar o LeSS, confira nossa visão geral dos frameworks Agile em escala.