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.
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:
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.
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.
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:
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!).
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
O LeSS escalona o próprio Scrum sem adicionar diferentes processos de escalonamento, artefatos ou eventos.
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.
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”.
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.
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.
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.
A melhoria contínua rumo à perfeição diz três coisas:
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.
O LeSS defende manter todas as equipes concentradas no produto inteiro, não apenas em sua pequena parte.
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:
E também há muito inventário nessas filas.
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:
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.
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:
Além disso:
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.
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:
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.
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.
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.
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.
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
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.
Um Sprint começa com o Planejamento do Sprint para todas as equipes ao mesmo tempo.
É dividido em duas partes.
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.
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.
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.
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.
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.
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.
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.
Além das práticas de excelência técnica, o LeSS não prescreve nenhum método ou técnica.
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:
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:
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.
Os capítulos destes livros estão disponíveis online:
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.
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.
Contate-Nos hoje para uma demonstração personalizada do SwiftEnterprise! Ou inscreva-se para atualizações abaixo.
Solicitar Demonstração