Muito tem se falado do Desenvolvimento Ágil em escala, cenário em que um número grande de pessoas trabalha com o Ágil em uma mesma organização. Buscando um espaço nesse mercado, surgiram nos últimos anos diversos frameworks e metodologias. As mais conhecidas são o o SAFe, do Dean Lefingwell, o LeSS, do Craig Larman e Bas Vodde, o DAD, do Scott Ambler, o Scrum@Scale, do Jeff Sutherland e o Nexus, do Ken Schwaber. Repare que os dois últimos foram criados pelos pais do Scrum, e são bem diferentes entre si.
Mas o que o framework Scrum, tal como descrito no Scrum Guide oficial, oferece com relação a esse assunto? Há, na realidade, poucas prescrições do Scrum básico para o trabalho em escala. Dentre elas, vale citar:
- o padrão do Scrum de um time pequeno, altamente flexível e adaptável se mantém o mesmo, desde para alguns poucos times até para milhares de pessoas distribuídas por uma rede de times, sempre pequenos, colaborando e interoperando no desenvolvimento, operação e manutenção de produtos;
- os times devem estar estruturados e empoderados pela organização para serem capazes de organizar e gerenciar o seu trabalho;
- toda a organização deve respeitar as decisões do Product Owner para possibilitar o sucesso de seu trabalho;
- os Scrum Masters planejam e lideraram a adoção e a promoção do uso efetivo de Scrum na organização, ensinando o framework e ajudando os colaboradores e demais partes interessadas a colocá-lo em prática, provocando as mudanças organizacionais necessárias e trabalhando junto a outros Scrum Masters com esse mesmo fim;
- no caso de múltiplos times trabalhando no mesmo produto, apenas um Product Backlog, comum a todos esses times, é utilizado como fonte de trabalho para eles. Nesse caso, podemos diferenciar o trabalho de cada time utilizando, por exemplo, um atributo nos itens do Product Backlog;
- caso haja uma definição de “Pronto” como parte das convenções, padrões ou diretrizes da organização, todos os times devem segui-la como um mínimo. Caso haja múltiplos times trabalhando em um mesmo produto, os times devem estabelecer em conjunto a definição de “Pronto”.
Acredito que qualquer método que se ofereça para escalar o Scrum deva seguir as regras acima, como um mínimo. Na minha opinião, LeSS é o framework mais alinhado com com os propósitos e princípios do Ágil e também com a própria definição do Scrum, já que respeita todas as prescrições para o trabalho em escala trazidas pelo Scrum Guide.
Faça sua inscrição no treinamento de LeSS da K21
Acho importante notar que, na K21, não utilizamos à risca nenhum método de escalar predefinido em nossos clientes, até mesmo porque nem sempre utilizamos Scrum como o caminho para o Ágil. Temos certeza – isso sim – do que não queremos. Mas vejo um alinhamento crescente da empresa, ainda que sem grande compromisso, com a simplicidade e lógica irrefutável do LeSS.
SCHWABER, K.; SUTHERLAND, J. The Scrum guide — the definitive guide to Scrum: the rules of the game. Nov. 2017. Disponível em: <https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf>. Acesso em: 9 mai. 2018.
Perguntas frequentes
Quais são os principais frameworks para escalar o Agil e o Scrum?
Os principais frameworks e metodologias para escalar o Agile e o Scrum incluem o SAFe, o LeSS, o DAD, o Scrum@Scale e o Nexus. Os dois últimos foram criados pelos próprios criadores do Scrum, Jeff Sutherland e Ken Schwaber, apresentando abordagens diferentes entre si para atender grandes organizações.
Como funciona o Product Backlog quando varios times trabalham no mesmo produto?
Quando múltiplos times trabalham no mesmo produto, deve existir apenas um Product Backlog comum a todos eles como fonte de trabalho. Para diferenciar as tarefas de cada equipe, podem ser utilizados atributos nos itens do backlog, garantindo centralização das demandas e respeitando as decisões do Product Owner.
O que o Scrum Guide orienta sobre a definicao de Pronto com multiplos times?
Quando múltiplos times trabalham em um mesmo produto, eles devem estabelecer em conjunto a definição de "Pronto". Além disso, caso a organização já possua convenções, padrões ou diretrizes gerais para essa definição, todas as equipes envolvidas precisam segui-las obrigatoriamente como um critério mínimo de qualidade.
Por que o LeSS e considerado alinhado com a definicao do Scrum?
O LeSS é considerado altamente alinhado ao Scrum porque respeita todas as prescrições do Scrum Guide para o trabalho em escala. O framework mantém a simplicidade e a lógica do Agile, preservando a estrutura de times pequenos, um único Product Backlog para o mesmo produto e a autonomia das equipes.
Pronto pra dar o próximo passo?
Conheça os cursos da K21 e leve essas ideias pra prática com quem vive agilidade todo dia.
Ver cursos K21