O LeSS, Large-Scale Scrum ou Scrum em Larga Escala, foi criado por dois agilistas com grande experiência em ajudar organizações com dezenas, centenas e, em algumas ocasiões, alguns poucos milhares de pessoas a usar o Scrum, em muitos casos em mais de uma localização geográfica. Craig Larman e Bas Vodde já escrevem sobre assunto há muitos anos, expondo suas ideias e experiências. Tive a oportunidade de interagir com ambos nos meus tempos de membro do Board de Diretores da Scrum Alliance e em outras ocasiões. Participei também de treinamentos de LeSS com cada um deles e fui um dos revisores do livro que eles escreveram sobre o framework. Esse livro serve de referência primária para o Scrum em larga escala, junto ao conteúdo do site oficial http://less.works. Para mais detalhes sobre o LeSS, sugiro fortemente a leitura desse material.
A ideia principal do LeSS é aplicar, a um contexto de larga escala, o Scrum tal como ele é. Ou quase. LeSS adiciona pouquíssimos elementos ao framework básico, chegando até a remover (ou, ao menos, deixar de mencionar) alguns aspectos, como a Meta do Sprint e a definição de Time de Scrum. Assim como o Scrum, LeSS é deliberadamente incompleto e utiliza a abordagem empírica da transparência, inspeção e adaptação para o trabalho, em vez de buscar aquela previsibilidade ilusória que dita o funcionamento de muitas organizações.
Simplicidade é a palavra-chave e o objetivo fundamental do LeSS é simplificar a organização grande e complexa – frase que já ouvi, tanto do Craig, quanto do Bas, em mais de uma ocasião.
A organização gira em torno do trabalho de Times de Desenvolvimento, que são seus elementos mais importantes. Esses times geram, cada um, funcionalidades prontas, de ponta a ponta, eliminando assim dependências assíncronas que gerariam filas e esperas. Apoiados por seus Scrum Masters, os times se auto-organizam na coordenação de seu trabalho, no planejamento conjunto do que cada um fará no Sprint, na colaboração durante o Sprint para resolver dependências entre eles de forma síncrona, na distribuição do conhecimento necessário para realizar o trabalho e na resolução de problemas organizacionais. Essa maior responsabilidade dos Times de Desenvolvimento reduz e até elimina a necessidade da gerência intermediária, achatando a hierarquia organizacional e simplificando a organização.
A mudança da mentalidade de projeto para a mentalidade de produto é mais uma das ideias poderosas que LeSS adota buscando a simplicidade. A organização move o foco de seu trabalho da realização contínua de projetos, que frequentemente representam grandes lotes de trabalho, para a entrega incremental de valor para seus usuários, em pequenos lotes. Ao contrário de projetos, que têm início e fim, o produto evolui continuamente, Sprint após Sprint, enquanto ele existir. Desaparece, assim, toda a complexidade da gestão de projetos que rege o funcionamento de grande parte das organizações de hoje. Ao mesmo tempo, ao adotar apenas um produto, mais amplo, priorizado em um único Product Backlog por um Product Owner, LeSS elimina a necessidade da gestão de portifólio. A formação de times também deixa de ser um problema, já que times estáveis e de longa duração trabalham sobre o produto.
O trabalho, realizado em pequenos lotes, é continuamente integrado entre os diversos times, permitindo a realização de entregas frequentes para os usuários do produto. Esses ciclos curtos de feedback realimentam continuamente o planejamento, maximizando a capacidade de adaptação da organização.
Fundamentos do LeSS
Vários times
Com LeSS, o desenvolvimento do produto é realizado por desde dois até cerca de oito times. Assim como no Scrum básico, cada time é pequeno, possuindo entre três e nove membros. Os times também são auto-organizados, multidisciplinares, estáveis, com membros dedicados, de longa vida e colocalizados. A grande maioria dos times produz funcionalidades com foco no usuário final.
Para um número de times superior a cerca de oito, abordarei o framework LeSS Huge em outro post.
Um produto
LeSS é desenhado para lidar com vários times atuando com Scrum sobre um e apenas um mesmo produto, representado em um Product Backlog. Mas a visão do produto ideal, no LeSS, é um tanto diferente. É comum grandes organizações dividirem seu portfólio em dezenas ou até centenas de pequenos produtos. LeSS, ao contrário, trabalha com uma definição mais ampla, englobando em um mesmo produto o que essas grandes organizações considerariam como vários.
Assim, podemos imaginar que uma organização que utiliza LeSS, no mundo ideal, terá apenas um produto amplo com todos os times trabalhando nele. Esse produto traz soluções de ponta a ponta com foco em seus usuários finais, ou seja, aqueles que o utilizarão, em vez de componentes, camadas ou etapas intermediárias.
É importante destacar que as regras de LeSS lidam com o desenvolvimento de apenas um produto por múltiplos times, não oferecendo regras nem práticas para como lidar com priorização entre diferentes produtos ou com dependências entre eles.
Um Product Owner
LeSS trata o papel do Product Owner de uma forma diferente que a configuração mais comum para adoções de Scrum, alinhando-se melhor, no entanto, com o Scrum básico. Nessa configuração prevalecente, cada time tem o seu Product Owner e cada Product Owner ter seu Product Backlog. Dessa forma, cada time se especializa em um determinado tipo de item, que irá compor seu Product Backlog local, priorizado por seu Product Owner.
Se olharmos para o conjunto total de times, é fácil entender que, como um todo, eles não conseguem dessa forma trabalhar nos itens de maior importância para a organização. Como cada time tem seu próprio Product Backlog, os itens de um determinado tipo chegam diretamente a seu Product Backlog correspondente. Assim, em qualquer determinado momento, haverá times limitados a trabalhar em itens de menor importância, já que não possuem o acesso e nem as habilidades necessárias para trabalhar em itens de outros tipos. Nesse cenário, times que estão lidando com itens de alta importância poderão ter, em espera no seu Product Backlog local, itens mais importantes do que aqueles em que estão trabalhando outros times, caracterizando a priorização inadequada. Mas, já que cada time realiza sua reunião de Sprint Planning apenas sobre sua lista, esse problema fica escondido em priorizações locais.
Ao contrário, com apenas um produto amplo com o uso do LeSS, há apenas um Product Owner, priorizando apenas um Product Backlog, que fornece itens para o trabalho de todos os times envolvidos. Dessa forma, a organização como um todo pode fazer uma melhor priorização. Teoricamente, o conjunto total de times pode selecionar diretamente, desse Product Backlog único, os próximos itens mais importantes, permitido uma visão sistêmica que leva a uma verdadeira priorização.
A escolha de que itens serão desenvolvidos por qual time no Sprint é feita em conjunto, em colaboração com o Product Owner, durante a reunião de Sprint Planning. Caso o conjunto de times não consiga selecionar os itens de mais alta importância, uma vez que determinados times não tenham os conhecimentos necessários, essa disfunção fica exposta e os times podem buscar gradualmente uma melhor distribuição de conhecimento entre eles, o que levará naturalmente a uma melhor priorização.
Um Incremento comum
No desenvolvimento com LeSS, todos os times trabalham, Sprint após Sprint, em um mesmo Sprint comum, sobre um código compartilhado, para gerar um Incremento do produto pronto comum. Cada time gera funcionalidades prontas de ponta a ponta, que são integradas continuamente ao produto em cada Sprint.
Durante o desenvolvimento no Sprint, cada time trabalha em torno do seu Sprint Backlog, mas os diferentes times irão colaborar uns com os outros conforme necessário, principalmente para resolver quaisquer dependências que sejam identificadas. Ao final, uma reunião de Sprint Review comum é realizada, em que os vários times apresentam para clientes e demais partes interessadas o Incremento produzido em conjunto, inspecionando e adaptando o produto como um todo.
Acredito que o leitor já pôde perceber que a adoção de LeSS implicará em uma mudança profunda na estrutura da maioria das organizações que optarem pelo seu uso.
Em futuros posts, pretendo abordar diferentes aspectos do LeSS, e tratar também do LeSS Huge, para quando há mais do que cerca de oito times trabalhando no desenvolvimento do produto.
