Introdução ao LeSS

(este é um trecho do capitulo 2 do futuro livro “Large-Scale Scrum: More with LeSS” ISBN 9780321985712)

Scrum em uma Única Equipe

Em poucas palavras … Scrum é um framework de controle de processos empíricos de desenvolvimento onde uma equipe auto organizada e multifuncional desenvolve um produto de forma incremental e iterativa. Ao final de cada (em média) Sprint de duas semanas, um completo potencial incremento lançável de produto ‘feito’ (ou resumindo, incremento lançável) é entregue e possivelmente lançado. Um único Product Owner é responsável por maximizar o valor do produto, priorizar itens (funcionalidades) no Product Backlog, e decidir de forma adaptativa qual a meta de cada Sprint baseada em inspeções frequentes. Uma Equipe é composta por cerca de sete pessoas que são responsáveis por entregar a meta da Sprint, elas possuem ou aprendem todas as habilidades necessárias. Não há nomenclaturas especiais de cargos e nem equipes especialistas. Um Scrum Master educa sobre o Scrum e como entregar valor através dele, e treina o Product Owner, Equipe e a organização para aplicá-lo. Não existem os papéis de gerente de projeto, líder de equipe ou qualquer outro papel dentro do Scrum. Uma Sprint começa com o Planejamento da Sprint, e termina com a Revisão da Sprint e a Retrospectiva da Sprint para inspecionar e adaptar, respectivamente, sobre o produto e os processos.

Controle de processos empíricos requer transparência, que é criada através do ciclo curto e iterativo de desenvolvimento de incrementos lançáveis. Enfatiza o aprendizado contínuo, inspeção, e adaptação sobre o produto e os processos. É baseado em reconhecer que os assuntos relacionados à P&D do produto são tão complexos e dinâmicos, para organizações com processos detalhados, estereotipados e com estilo “uma luva serve para todas as mãos”.

No Scrum Guide e no Scrum Primer, o Scrum é descrito para uma única equipe.

LeSS

Large-Scale Scrum (LeSS) trata-se do Scrum aplicado para várias equipes trabalhando juntas em um mesmo produto. Por que LeSS? Ele é similar ao Scrum para uma única equipe.

Para grandes grupos, o LeSS estabelece um equilíbrio sutil entre elementos concretos e definidos e o controle de processos empíricos.

E assim como uma única equipe Scrum, o LeSS é (1) leve, (2) simples de entender, e (3) difícil de dominar devido à complexidade.

Background

Em 2002, quando Craig escreveu Agile & Iterative Development, muitos ‘sabiam” que o desenvolvimento ágil era para pequenos grupos. Entretanto, nós ficamos interessados -e fomos cada vez mais solicitados- em aplicar Scrum em desenvolvimentos de produtos muito grandes. Então, desde 2005 Craig e Bas se uniram para trabalhar com os clientes para escalarem Scrum. Atualmente, os dois frameworks LeSS (LeSS básico e LeSS Huge) estão sendo adotados em grandes grupos de produtos pelo mundo em diversos segmentos, incluindo:

• fabricantes de equipamentos de telecom como Ericsson & Nokia Networks
• bancos de investimentos e varejo como JPMorgan and BAML
• empresas de sistemas de negociação como ION Trading
• fabricantes de games como bwin
• terceirizadoras como Valtech India

Para quantificar ‘grande’, dentro deste contexto, nós já estivemos envolvidos com a adoção de LeSS Huge em grupo de produto com cerca de 2500 pessoas, 10 silos de desenvolvimento, dezenas de milhões of de linhas escritas em C++, com hardware customizado.

Qual o tamanho médio de uma equipe de grupos de produtos que utilizam LeSS? Talvez entre três e cinco equipes distribuídas entre um ou dois silos.

Baseado em nossas experiências, entre 2008 e 2010, nós publicamos dois volumas sobre desenvolvimento ágil escalado usando os fremworks LeSS:

1. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, que explica as mudanças de pensamento, liderança e organizacionais.
2. Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum, que explica os conselhos concretos para escalar Scrum, incluindo gerenciamento do produto, arquitetura, planejamento, multisilos, terceirização e contratos.

Este é o terceiro livro da série LeSS, uma espécie de abertura. Ele é um resumo dos outros livros. Se você quiser mais detalhes sobre o LeSS, leia os primeiros dois volumes ou o site less.works.

Princípios e Temas do LeSS

Scrum em larga escala é Scrum— Não é um “novo e melhorado Scrum.” Pelo contrário, o LeSS é sobre descobrir como aplicar os princípios, elementos e o propósito do Scrum em um contexto de grande escala.

Controle de processos empíricos—Inspeção e adaptação dos produtos, processos, estrutura organizacional e práticas para criar uma organização adequada baseada em Scrum, em vez de seguir uma fórmula detalhada. E controle de processos empíricos exige e cria…

Transparência—Baseada em itens tangíveis ‘feitos’, ciclos curtos, trabalhando em equipe, definições comuns e mantendo o medo fora do local de trabalho.

Mais com menos—(1) No controle de processos empíricos temos: mais aprendizado com processos menos definidos. (2) No pensamento enxuto (Lean) temos: mais valor com menos desperdício e custos altos. (3) No dimensionamento temos menos papéis, artefatos e grupos especiais.

Foco em todo o produto—Um Product Backlog, um Product Owner, um potencial incremento lançável de produto, uma Sprint-independentemente se há 3 ou 33 equipes. Os clientes querem o produto, não uma parte somente.

Foco centrado no cliente—Identificar o valor e o desperdício na visão do cliente pagante. Reduzir o ciclo de tempo de acordo com sua perspectiva. Aumentar os loops de feedback com clientes reais. Todo mundo entender como seu trabalho atual se relaciona diretamente com os benefícios gerados para os clientes pagantes.

Melhoria contínua rumo à perfeição—Criar e entregar um produto o tempo todo, sem custos e sem defeitos, para encantar totalmente os clientes, melhorar o ambiente, e tornar a vida melhor. Fazer experiências de melhorias tanto humildes quanto radicais a cada Sprint neste sentido.

Pensamento sistêmico—Ver, compreender e otimizar o sistema como um todo (e não apenas partes dele), e usar modelagem para explorar a dinâmica do sistema. Evite as sub-otimizações que se concentram na “eficiência” ou “produtividade” dos indivíduos e das equipes individuais. Os clientes se preocupam com o fluxo e o tempo total do ciclo de vida do produto (da concepção até o retorno financeiro), e não os passos individuais.

Pensamento enxuto (Lean)—Criar um sistema organizacional cujo fundamento é ter “gerentes como professores” que aplicam e ensinam pensamentos sistêmicos e pensamentos enxutos, gerenciam para melhorar e “vão até Gemba” (Nota do Tradutor: Gemba é um termo japonês que significa: o lugar onde a verdade pode ser encontrada). Adicionar os dois pilares do respeito pelas pessoas e melhoria contínua. Tudo com o objetivo de atingir a perfeição.

Teoria das filas—Entender como sistemas com filas se comportam em ambientes de P&D, e aplicar essas informações para gerenciar tamanhos de fila, limites de trabalho em andamento, multitarefa, pacotes de trabalho, e variabilidade.

Dois Frameworks: LeSS & LeSS Huge

O Scrum em Larga Escala possui dois frameworks:

• LeSS: De 2 a 8 Equipes.
• LeSS Huge: A partir de 8 Equipes, até algumas milhares de pessoas por produto.

O termo ‘LeSS’ (Menos) significa tanto Large-Scale Scrum (Scrum em larga escala) quanto um framework menor e básico. Nós achamos isso conveniente.

Framework LeSS—O framework (básico) LeSS é para um único Product Owner (PO) e para duas até oito equipes. Há um real Product Owner geral (que literalmente é “dono do produto”) para um único real produto lançável, que gerencia um único Product Backlog trabalhado por todas as equipes em uma Sprint, otimizando para a totalidade do produto.

‘Oito’ não é um número mágico para a escolher entre LeSS e LeSS Huge. O ponto de inflexão é situacional. Em algum ponto, (1) o único PO geral não consegue mais ter uma visão geral de todo o produto, (2) o PO não consegue equilibrar entre o foco externo e interno, e (3) o Product Backlog é tão grande que se torna difícil para uma pessoa para trabalhar com ele.

Quando o grupo perceber as dicas acima, hora de mudar. Talvez para LeSS Huge, mas tente começar de forma menor e simples, sem tornar gigante.

O restante desta seção principal explica Framework Less menor; o Framework LeSS Huge será abordado posteriormente.

Elementos do Framework LeSS

Os elementos do framework LeSS (menor) são essencialmente os mesmos do Scrum com uma única equipe:

Papéis— um único Product Owner, dois a ‘oito’ Equipes, Scrum Masters.

Artefatos—Há um único potencial incremento lançável de produto, um único Product Backlog, e Sprint Backlogs separados para cara Equipe.

Cerimônias—Há uma única Sprint para todo o produto, incluindo todas as equipes and finalizando com um único potencial incremento lançável de produto. Detalhes sobre as cerimônias serão explicados nas histórias seguintes do LeSS e em capítulos separados.

Além destes elementos, o LeSS inclui:

Regras—Coisas que o grupo deve seguir e fazer, como Planejamento de Sprint Partes 1 e 2, e um único Product Backlog para o produto lançável. Existem regras do LeSS relacionadas com papéis, artefatos e cerimônias.

As poucas e simples regras do LeSS equilibram a baixa ‘prescritividade’ necessária para controle de processos empíricos e a necessidade, especialmente para os novos adotantes, de alguma direção específica para saber o que e o como para começar. E, em seguida, ser capaz de criar real transparência com o LeSS. O termo “ser mais específico quando se inicia” reflete as necessidades introdutórias de aprendizado reconhecidas em vários modelos de aprendizagem. O trompetista de jazz e professor Clark Terry resumiu a progressão de aprendizado: imitar, assimilar, inovar. Alguns conhecem isso como Shu-Ha-Ri (seguir, romper, transcender) em Akido.

Orientações—Conselhos para tentar, com base na experiência dos adotantes do LeSS, ações como coordenação entre as equipes durante a Sprint. Pode ou não ser apropriado, e são áreas para experiências de melhoria contínua.

Como compreender os elementos do LeSS na prática? Vamos contar algumas histórias …

Histórias sobre LeSS: Fluxo de Equipes & Cerimônias

Esta história enfatiza o fluxo de pessoas e equipes através das cerimônias de uma Sprint LeSS. A história seguinte enfatizará o fluxo de funcionalidades de clientes através das cerimônias.

Em uma manhã ensolarada em Londres, Dave caminha para o edifício ‘Gherkin’ no coração financeiro da cidade. Ele pega o elevador até o 17º andar, e se dirige para a sala onde sua equipe trabalha-Equipe de Negociação, que coletivamente sabe muito sobre a negociação de títulos europeus. Devi já está lá, mas não o restante da equipe. “Bom dia!”, ela cumprimenta Dave. “Apenas um lembrete: Nós somos os representantes da equipe nesta Sprint e a Primeira Parte do Planejamento da Sprint começa em 10 minutos.” “Certo”, diz Dave, “Eu vou pegar um café expresso e te encontro na sala grande”.

Planejamento da Sprint - Parte 1

Poucos minutos depois, Dave senta-se em uma cadeira na sala grande. Devi e alguns outros desenvolvedores chegaram logo após Dave e agora há quorum-há 10 representantes das cinco equipes que trabalham em seu principal produto para obrigações comerciais e gestão de riscos. Sam, o Scrum Master das equipes de Comércio e Margem, já está lá. Ele está planejando para observar e orientar conforme necessário. O grupo está começando sua 4ª Sprint de duas semanas usando LeSS, e chegou a hora de iniciar um timebox de duas horas para a Parte 1 do Planejamento da Sprint.

Paolo entra e diz: “Oi!” para o grupo. Ele é o Product Owner e também o principal Gerente de Produto. Dois outros Gerentes de Produto já estão sentados. Paolo distribui 22 cartas ordenadas em uma mesa, e diz: “Aqui está a minha proposta para esta Sprint. Além de muitas características do mercado brasileiro, alguns dos itens são para novos relatórios de auditoria para títulos derivados dos EUA”.

Sam lembra o grupo: “Não deixem que todos os itens de maior prioridade sejam tomados por uma equipe. Tentem distribuí-los entre as equipes”.

Dave e Devi caminham até a mesa (junto com os outros representantes) e eles escolhem dois cartões com itens relacionados a obrigações europeias, cuja equipe fez um detalhado Refinamento do Product Backlog ao longo das últimas Sprints. Eles escolhem um terceiro item relacionado à gestão geral, assunto que a maioria das equipes entende muito bem. Um minuto depois, Dakota, da Equipe de Margem, ao analisar os cartões da Equipe Comercial, pergunta para Dave e Devi: “nós podemos fazer sua funcionalidade de gestão geral? Fizemos algo semelhante na Sprint passada. Nós podemos trocar com este novo relatório muito simples que pegamos”. Eles concordam.

Cerca de cinco minutos depois, todos os representantes das equipes tinham escolhido um total de 18 cartões, deixando 4 cartões com relativamente baixa prioridade sobre a mesa. Paolo olha para estes cartões, pega um, e diz: “Este aqui é muito importante para mim nesta Sprint. Vamos encontrar uma maneira de trocá-lo com um dos itens que vocês já tenham escolhido”.

Depois de resolvida a questão, é hora de cada equipe criar uma Meta da Sprint e esclarecer as questões remanescentes-há sempre perguntas, mesmo que esses itens tenham sido esclarecidos no refinamento do Product Backlog em Sprints anteriores. Em paralelo, Dave, Devi, e os outros escrevem perguntas para os seus itens escolhidos em papéis de flip-chart. Paolo e os os outros dois Gerentes de Produto se dividem e visitam diferentes pessoas, respondendo a perguntas. Cerca de 45 minutos depois, todas as questões remanescentes que puderam ser respondidas, foram respondidas.

Então Sam anuncia: “Um lembrete: A última coisa que precisamos falar sobre juntos é sobre coordenação.” Don, da Equipe de Margem, aponta que um dos itens sobre obrigações europeias envolve trabalho compartilhado com dois itens da Equipe de Margem. Dave sugere: “Vamos conduzir nossa segunda parte da reunião de Planejamento da Sprint em conjunto”, e Don concorda.

Planejamento da Sprint - Parte 2

Depois de uma pausa, cada equipe conduz sua própria segunda parte do Planejamento da Sprint que, na maioria das vezes, é idêntica a reunião conduzida por uma única equipe Scrum. Mas nesta história …

Equipes de Comércio e Margem realizam a segunda parte do Planejamento da Sprint através de uma reunião multi equipes: suas reuniões são realizadas na grande sala, trabalhando em mesas separadas. Elas descobrem grandes questões de design sobre os seus itens relacionados. Algumas dessas perguntas são respondidas rapidamente com discussão e desenhos em um quadro branco, mas algumas das questões mais complexas precisam ser mais discutidas. Para estas questões, as equipes concordam em conduzir uma oficina multi equipe de design após o Planejamento da Sprint. As equipes reconhecem que algumas premissas do planejamento podem mudar.

Pouco depois do Planejamento da Sprint, um representante de cada equipe atualiza o Product Backlog geral (uma planilha do Google) com as previsões de itens que cada equipe fará na Sprint.

Oficina de Design Multi Equipe

Depois de outra pausa, Dave e Devi da Equipe de Negociação, e algumas pessoas da Equipe de Margem realizam uma timebox de uma hora para uma oficina de design multi equipe. Em torno de um grande quadro branco eles fazem uma modelagem ágil até que eles tenham alguma clareza e acordo sobre uma abordagem de design comum e trabalho técnico compartilhado. Felizmente, as conclusões não impactam seriamente os seus planos de Sprint já existentes, mas eles se sentem desconfortáveis ​​com o seu processo, reconhecendo que poderiam ter previsto a necessidade de resolverem estas grandes questões de design com mais antecedência.

Retrospectiva Geral

No segundo dia da Sprint, Sam e os outros Scrum Masters, o Product Owner Paolo, uma administradora do site chamada Maria, e um representante de cada uma das outras equipes, se reúnem para uma Retrospectiva geral de 90 minutos relacionada a última Sprint. (Eles não poderiam realizar uma Retrospectiva geral no final da Sprint, porque ela terminou com as Retrospectivas regulares em nível de equipe.) Eles se concentram na melhoria de todo o sistema: como coordenar, compartilhar informações e resolver problemas de todos os grupos durante a Sprint? Anteriormente, eles haviam tentado reuniões Scrum-of-Scrums e não acharam que foi muito eficaz. Sam explica a técnica de Espaço Aberto(Open Space) e eles concordam em tentar isso nesta Sprint.

Dia 4 - Coordenação (coordenação em um exemplo de um dia no LeSS)

No LeSS, cada equipe executa sua Daily Scrum, como de costume. Mas, para apoiar a coordenação entre as equipes de Negociação e Margem, Devi se junta a Daily Scrum da Equipe de Negociação. Do outro lado, Don se junta a Daily Scrum da Equipe de Negociação.

Tal como acordado na Retrospectiva geral, Dave e Devi participam de uma reunião de grupo Open Space de 45 minutos para a coordenação da Sprint com os representantes das equipes. Sam atua como facilitador para ensinar o grupo.

Don é o coordenador da comunidade de práticas de testes (CoP) deste ano. Ele se reúne por meia hora com um representante de cada equipe para que eles possam ouvir a proposta do Dakota relacionada com a ferramenta automatizada de testes de aceitação. A proposta foi aceita com entusiasmo, e Dakota e sua equipe de funcionalidades de voluntariaram para fazerem o trabalho na próxima Sprint.

Dave é um membro da comunidade de práticas (CoP) de arquitetura. Não há nenhuma reunião nesta Sprint, mas ele quer executar um spike de meio-dia na próxima Sprint para um grupo exploratório de programação com uma nova tecnologia. Ele submete a sua ideia a outros membros em sua ferramenta colaborativa de comunidade de práticas (CoP).

O sistema de compilação e integração contínua (CI) parece ter um bug estranho. A Equipe de Negociações é responsável por analisar isso nesta Sprint, e é uma das especialidades secundárias de Devi, que se voluntaria para corrigi-lo e pede para Dave para sentar junto com ela para ajudá-lo a aprender mais sobre o assunto.

Mais tarde, Devi vai até uma das Gerentes de Produto e pergunta se ela está livre por alguns minutos para olhar para o primeiro item que a equipe terminou. A Gerente de Produto está livre, então eles examinam o item e Devi volta com algumas pequenas melhorias para a equipe para fazer.

No final do dia Dave está codificando o segundo item, com o restante da Equipe de Negociação. Ele verifica uma pequena variação de performance após cada ciclo de TDD de 10 minutos, ao integrar continuamente com sua equipe e com o grupo de produtos. Ele olha por cima de seu grande e visível tela verde-vermelha e repara que o sistema de integração contínua (CI) está a rodando todos os testes de todo o grupo.

PBR Geral

No quinto dia, Dave e Devi participam de um Refinamento Geral do Product Backlog refinement (PBR), com representantes de cada equipe, o Product Owner, e os outros dois Gerentes de Produto. O grupo divide alguns grandes itens, faz uma análise rápida e estima.

PBR das Equipes

No sexto dia, a Equipe de Negociação executa sua reunião de Refinamento do Product Backlog (PBR), onde todos os membros da equipe participam juntos. Às vezes, cada equipe realiza seu PBR separadamente, mas nesta história …

Com base na última sessão de Refinamento Geral do Product Backlog, Dave e Devi sabem que o tema de sua sessão de Refinamento de Product Backlog da equipe é referente às novas exigências regulatórias dos EUA e também que outras duas equipes frequentemente trabalham nesta área. Portanto, as três equipes decidir realizar uma sessão de Refinamento de Product Backlog Multi Equipe na mesma sala grande, com dois Gerentes de Produto e um advogado do Departamento Jurídico que se encontrou recentemente com os reguladores. As equipes fazem análise de rotação, e alguns outros padrões de divergência-convergência.

Revisão da Sprint

Finalmente, é o último dia e hora para uma Revisão de Sprint de duas horas! Há apenas um Revisão geral em nível de produto. Porque há cinco equipes e muitos itens para inspecionar …

O grupo começa com uma Revisão de uma hora, estilo bazar “divergente”, com muitos laptops na sala, cada um mostrando diferentes conjuntos de itens. O Product Owner, outros Gerentes de Produto, e algumas pessoas de vendas estão inspecionando itens diferentes em paralelo. Alguns membros da equipe permanecem com seus laptops para coletarem feedback, e outros visitam itens que lhes interessam.

Depois de uma hora, o grupo parte para a segunda fase da Revisão. Primeiro, usando um laptop e projetor, Paolo mostra a planilha com o Product Backlog, e marca os itens inicialmente previstos que foram ‘Concluídos/Done’. Em seguida, ele dá um feedback resumido sobre os itens que ele estava intimamente inspecionando, e solicita aos outros Gerentes de Produto e pessoal de vendas a fazerem o mesmo. Paolo apresenta e discute 3 itens críticos com todo o grupo. Em seguida, ele confirma que quer realmente liberar o produto agora, para um subconjunto dos negociadores em um programa beta-teste. Finalmente, Paolo explica sua direção provável para a próxima Sprint.

Retrospectivas das Equipes

Após uma pausa, a Equipe de Negociações executa sua Retrospectiva de Sprint. Ela decidiu que manter a oficina de design multi equipe depois do Planejamento da Sprint (e não antes) não era muito bom. Na próxima Sprint ela decidiu realizar logo uma oficina de design para alguns itens complexos e inter-relacionados, de modo que as equipes possam especular sobre um design comum, e identificarem prováveis ​​oportunidades de trabalho em cooperação. Na próxima Retrospectiva geral, eles sugerirão para identificar e discutir os itens inter-relacionados durante o PBR.

FIM

A Sprint termina. Sam convida toda a equipe para se juntar Dave e ele no pub Belga ao final da rua para comemorar o aniversário de Dave.

Histórias sobre LeSS: Fluxo de Funcionalidades & Cerimônias

Esta história enfatiza o fluxo de funcionalidades de clientes através de cerimônias, versus a história anterior sobre pessoas e equipes.

Ariel está tão ansiosa para embarcar em um luxuoso voo de primeira classe na Virgin Atlantic de volta a Londres, após esta reunião terminar. Ela lança seu sorriso de 1000 watts para o regulador financeiro dos EUA, aperta a mão, e pega um táxi para JFK.

Após o final de semana, ela está sentada com Paolo (o Product Owner e principal Gerente de Produto) em seu escritório, e admira a vista do Gherkin ao redor de Londres. Ariel, uma gerente de produto que é especialista em requisitos sobre regulamentação, resume em alguns cartões de papel as novas regras da área que vão impactar seu produto, e quais os atuais clientes que ela acredita que irão solicitar certos requisitos primeiro. Paolo aponta para as cinco cartas, e pergunta: “Então, isso abrange todo o trabalho, certo?” Ariel sorri e diz: “Este é regulatório, Paolo. Nunca acaba.” “Paolo pergunta:” Você pode colocar estes itens no Product Backlog para mim agora, não necessariamente ordenados na parte inferior? “ “Claro.”

Uma semana depois, Paolo conversa com Ariel, “Em breve, eu quero começar a entregar uma das áreas regulatórias, para os derivados de obrigações. Nas próximas reuniões de PBR da próxima Sprint, eu vou pedir as equipes se concentrarem no refinamento destes requisitos. Você é a perita, por isso, por favor participe do PBR Geral e em qualquer PBR das equipes caso elas necessitem de você. A reunião será realizada nos dias 24 e 25 deste mês. Além disso, crie uma página wiki com links para os novos documentos regulatórios, para compartilhar com as equipes. “Claro”, diz Ariel,” … e a página já está configurada.”

PBR Geral

Ariel entra na grande sala para uma oficina de PBR Geral de meio-dia. Paolo já está lá, junto com Peter (o outro gerente de produto), e 10 membros de cinco equipes. Paolo inicia, “Nós temos uma grande quantidade de trabalho em torno das regulamentações dos EUA. Em algumas Sprints quero começar a entregar as funcionalidades por causa da data limite de uma regulamentação do ano fiscal. Vamos saber melhor depois de algum refinamento e estimativa, mas eu não ficaria surpreso se envolver três ou mais equipes para implementação. “

O grupo se organiza em um semi círculo de cadeiras ao redor de um grande quadro branco, com Ariel no quadro. No lado esquerdo, ela escreve “regulamentações para derivados de obrigações.” Então, em conversa com o grupo, ela esboça uma árvore de ramificação dos requisitos menores, divide, explica e responde a perguntas. Após 30 minutos, o requisito original foi dividido em 16 requisitos menores.

Após uma pausa, o grupo cria 16 cartões para os novos itens. Eles escolhem sete dos itens que Paolo e Ariel acha que são especialmente críticos, mas também não muito claros (alguns dos requisitos estão claros e referentes à simples relatórios para os auditores).

Usando a técnica de especificação pelo exemplo que Sam (a Scrum Master) ensinava, o grupo discute e cria um exemplo para cada um dos sete itens críticos, mas pouco claros. Depois de uma hora e meia, o grupo tem seus exemplos e uma melhor compreensão compartilhada.

Após outra pausa curta, todos os membros da equipe juntos estimaram os 16 novos itens, usando planning poker e pontos relativos, comparando os pontos contra alguns alguns dos itens estimados existentes no Product Backlog.

Cerca de metade dos itens foram estimados como factíveis em um terço da Sprint ou menos, por uma equipe. Esta é orientação do grupo para definir o tamanho máximo. O restante são itens maiores, e irão ser divididos em uma oficina de PBR posterior.

Paolo olha para todos os 16 cartões com Ariel e remove alguns que são relativamente de baixa prioridade. Apontando para os itens restantes Paolo diz: “Eu vou querer aqueles em breve. Por favor, se concentre em terminá-los”.

No final da oficina, os membros da equipe olham os itens e decidem que três das cinco equipes devem se concentrar neles: duas equipes que trabalharam anteriormente em títulos dos EUA, e a Equipe de Negociações, uma vez que os regulamentos europeus futuros devem ser semelhantes.

PBR Multi Equipe e PBR Equipe

No dia seguinte, a Equipe de Negociação e as duas equipes dos EUA (TooBigToFail e NotDerivative) realizam oficinas de PBR de Equipe de dia inteiro. Elas têm 12 itens regulatórios para finalizarem o mais rápido possível. Uma vez que muitos deles estão relacionados, elas decidem realizar uma oficina de PBR multi equipe juntos na sala grande. Os Gerentes de Produto Ariel e Peter se juntam, mas não Paolo.

O grupo faz um trabalho rotativo para refinar os itens: Cada equipe começa a refinar um item diferente em uma área de trabalho separada na sala, cada uma com um quadro branco e projetor. Ariel está com a Equipe de Negociação e eles começam a refinar um relatório regulamentar. Peter está com a Equipe TooBigToFail, esclarecendo um requisito de risco. A Equipe NotDerivative trabalha sozinha.

Aos 30 minutos, o cronômetro fez ding! A Equipe de Negociação caminha para a área da Equipe TooBigToFail, a Equipe TooBigToFail caminha até a área da Equipe NotDerivative e a alguns membros da equipe NotDerivative caminham para a área da Equipe de Negociação. Ariel e Peter não se movem, e um dos membros da Equipe NotDerivative também fica para trás para explicar as coisas para a equipe que está chegando. O cronômetro é reiniciado, as pessoas permanecem explicando os resultados atuais e, em seguida, as equipes continuam com o refinamento.

Durante o dia, conforme os diferentes requisitos regulatórios tornam-se claros, ou são deixados para trás com questões que terão ser exploradas mais tarde, os novos itens são introduzidos em uma área de trabalho. Alguns dos itens maiores são divididos em dois ou três novos menores.

Duas vezes durante o dia as equipes param o seu trabalho de análise, e fazem algumas estimativas, o que elas fazem separadamente e em paralelo para diferentes itens, mais uma vez, comprando estas estimativas contra alguns dos itens já estimados no Product Backlog.

O Dia Seguinte

Na manhã seguinte após a oficina de PBR, Peter (que muitas vezes ajuda Paolo com isso):

• Atualiza o Product Backlog com os novos itens divididos derivados do requisito original, e exclui o original
• Adiciona links para a nova página wiki de detalhes dos itens, criados ontem na oficina de PBR
• Registra as últimas estimativas, e os registros que os itens foram considerados preparados (ready) pelas equipes

Ao final do dia, Ariel e Peter reunem-se com Paolo para revisarem as alterações do Product Backlog, responderem a perguntas de Paolo, e reordenarem.

Paolo destaca os novos itens para relatórios regulatórios de auditoria e os coloca no topo da ordem; ele decide que ele quer fazê-los na próxima Sprint porque rapidamente entregando os relatórios para os auditores muita pressão acaba. Um conjunto de itens que ele agora percebe são muito menos importantes do que ele e Ariel pensaram, e ele os coloca com prioridade muito baixa, podendo ficar deste jeito por meses até ele retomá-los.

Planejamento de Sprint - Parte 1

Paolo coloca 22 cartas ordenadas em uma mesa, e diz: “Aqui está a minha proposta para esta Sprint. Além de muitas funcionalidades do mercado brasileiro, alguns dos itens são para novos relatórios de auditoria para títulos derivados dos EUA”.

LeSS Huge

Áreas de Requisitos

Com 1000 ou mesmo apenas a 100 pessoas em um único produto, dividir e conquistar é inevitável. O desenvolvimento tradicional em larga escala divide-se em:

• grupos de função única (grupo de análise, o grupo de teste, …)
• grupos de arquitetura-componentes (grupo de camada de interface do usuário, o grupo do servidor, o grupo de acesso a dados, o grupo de componentes, …)

Este tipo de organização possui um desenvolvimento inflexível e lento, com (1) níveis elevados de desperdício (inventário, trabalho em andamento, handoff, dispersão de informação, …), (2) ROI muito demorado, (3) planejamento e coordenação complexa, (4) gerenciamento sobrecarregado, e (5) fraco feedback e fraca aprendizagem. E é organizado em torno de habilidades individuais e arquitetura ‘interna’, em vez focar em torno do valor do cliente ‘externo’.

Mas no framework LeSS Huge, quando existem mais que ‘8’ equipes, você não as divide por funcionalidade ou arquitetura; você as divide pelas principais áreas de preocupações dos clientes chamadas de áreas de requisitos. Isso reflete o princípio foco no cliente do LeSS.

Por exemplo, em um produto de Valores Mobiliários (para negociar e gerenciar valores mobiliários), algumas das principais áreas de requisitos de clientes são:

• processamento da negociação (desde a captura comercial até a liquidação)
• manutenção de ativos (por exemplo, lidar com um desdobramento de ações, dividendos)
• nova integração no mercado (por exemplo, Brasil)

Conceitualmente em um Product Backlog, um atributo “área de requisito” é adicionado, e cada item é classificado em somente uma uma área:

Ordem	Item	Área de Requisito	…
1	B	integração mercado
2	C	processamento negoc.
3	D	manutenção ativos
4	F	integração mercado
…

Em seguida, as pessoas podem se concentrar em uma Área do Product Backlog (conceitualmente, uma visão do Product Backlog), como por exemplo a área de integração no mercado

Ordem	Item	Área de Requisito	…
1	B	integração mercado
4	F	integração mercado

Product Owners e Equipes por Área

Em LeSS Huge é introduzido um novo papel. Cada área de requisitos Product Owner de Área que se especializa em uma área de requisitos e concentra-se no Product Backlog desta Área. E, várias (e não somente uma) equipes de funcionalidades atendem o Product Onwer de Área e também se especializam nessa área de requisitos.

Por exemplo, o produto Valores Mobiliários tem:

• Um Product Owner geral e três (um por área) Product Owner de Área, cada um apoiado por outros Gerentes de Produto
• A (maior) área, processamento de negociações tem seis equipes
• E quatro equipes em cada uma das outras áreas de requisitos

Uma área de requisitos sempre têm o mesma quantidade fixa de equipes? Não. Ao longo do tempo, caso uma área sofra alterações de importância, as equipes podem se juntar ou sair-muito provavelmente de ou para outra área existente.

Elementos do Framework LeSS Huge

Em resumo, no LeSS Huge cada área de requisitos funciona como um framework menor do LeSS, com cada área trabalhando em paralelo em uma única Sprint geral. As variações refletidas nos períodos de transição em grupos gigantescos são discutidos nos capítulos de Adoção e Organização por Valor ao Cliente.

Papéis- igual ao LeSS, exceto: dois ou mais Product Owners por Área, e ‘quatro’ a ‘oito’ Equipes em cada área de requisitos. Existe um Product Owner (que se concentra na otimização de todo o produto) e os vários Product Owners por Área que formam a Equipe de Product Owner. Normalmente existem outros gerentes de produtos para apoio em grupos de produtos muito grandes.

Uma área de requisitos normalmente é composta por pelo menos quatro equipes. Exceções?

• Uma situação de transição inicial, quando o grupo está crescendo gradualmente em uma nova área onde é esperada chegar a ter quatro ou mais equipes. Então, comece pequeno e simples, com uma equipe.
• Quando for necessário reequilibrar as equipes de uma área com uma demanda decrescente para uma área com demanda crescente; uma área poderia ir de quatro para três equipes. Em última instância, unir duas áreas pequenas reduzidas para ter uma nova área maior.

Por pelo menos “quatro” equipes? Qual é o problema com pequenas áreas? Muitas áreas minúsculas reduzem a visibilidade sobre as prioridades gerais do Product Backlog, aumentam a complexidade de coordenação, e criam equipes que se são muito especializadas e que não possuem a flexibilidade (agilidade) para assumir itens emergentes de maior valor.

Artefatos-igual ao LeSS, exceto: uma coluna de área de requisitos no Product Backlog único, e, consequentemente, um visão de Product Backlog de Área para cada área de requisitos.

Eventos - Ainda há apenas uma Sprint comum para o produto; que inclui todas as equipes e termina em um potencial incremento lançável de produto. Do ponto de vista de uma equipe que trabalha em uma área, o LeSS Huge se parece como o LeSS com relação aos eventos. Outros detalhes sobre eventos serão ilustrados na próxima história.

Assim como o LeSS, existem regras and orientações no LeSS Huge, que serão introduzidos na história seguinte, e concretizadas nos próximos capítulos.

História sobre LeSS Huge

Peter ouve uma nova voz no corredor, e sai de seu escritório para acolher calorosamente Ariel para seu novo emprego. Como gerente de operações de nível médio na divisão de Títulos de uma grande empresa comercial e Product Owner geral para o seu sistema interno de Valores Mobiliários, ele também é responsável por encontrar e reter talentos para sua Equipe de Product Owners. E ele acha que Ariel é um achado fantástico, pois sua experiência é exatamente a necessária para lidar com algumas novas grandes exigências.

Durante a entrevista de emprego recente -quando Ariel era uma gerente de produto especializada em questões regulatórias em uma empresa que fez um sistema para a negociação de títulos- Peter tinha apresentado a situação. “Ariel, depois do último acidente, os reguladores estão caindo com força e eles exigem que sejamos compatíveis com Dodd-Frank. Neste momento, não sabemos o que significa exatamente ou como isso afetará nosso sistema. Você tem incrível conhecimento deste espaço, e uma grande rede profissional com os reguladores. Eu adoraria se você se juntasse ao nosso grupo e nos ajudasse a descobrir como lidar com isso.”

Uma Grande Surpresa

Alguns dias depois…

Peter dá as boas-vindas a Ariel, Rob e Krishna em seu escritório. Rob é Product Owner da Área de mercado onboarding, e Krishna é uma Scrum Master da área de processamento de comércio.

Peter disse: “Como você sabe, Dodd-Frank está chegando, e a coisa é enorme. O que você não sabe é que esta manhã os reguladores nos chamaram e querem que tomemos medidas agora. Eu estava trabalhando com a premissa de que poderíamos começar no próximo ano. Então vamos ter que nos adaptar a este grande momento.”

“Eu não acho que os detalhes estejam claros para alguém -até mesmo para os reguladores. E não sabemos como isso afetará nosso sistema e quanto trabalho isso vai dar! Mas agora Ariel se juntou a nós e ela tem uma compreensão melhor do que ninguém, embora ela seja totalmente nova com os nossos sistemas. Então, como podemos ajudá-la a começar a lidar com esse montão de trabalho?”

Rob, Krishna e Peter discutem abordagens diferentes. Rob pergunta: “Vocês sabem sobre os Zumbis Disléxicos, certo?” Krishna e Peter acenam com a cabeça. Todo mundo sabe sobre eles - e não apenas seu nome. Os Zumbis Disléxicos provavelmente possuem a experiência mais ampla de todas as equipes. Eles trabalham há anos e eles eram um verdadeira pé no saco quando eles adotaram LeSS. A equipe continha dois ex-membros de seu grupo de arquitetura agora abandonado mais duas pessoas que estavam trabalhando no sistema há mais de quinze anos. A resistência daqueles quatro contra a adoção do LeSS era lendária, pois temiam perder a “perspectiva do sistema”. Para surpresa deles, aconteceu o contrário! Devido ao seu profundo conhecimento eles continuamente pegavam itens difíceis de desenvolver, eles participavam regularmente como peritos-professores em oficinas de arquitetura com os recém-chegados, e Tom-um dos antigos arquitetos PowerPoint-agora está liderando a Comunidade de Prática de arquitetura. Quando ele toma cerveja suficiente, ele admite que trabalhar mais perto com o código e testes realmente aumentou a sua verdadeira compreensão do sistema.

Rob continua: “Se alguma equipe puder ajudar rapidamente Ariel a entender melhor o tamanho e o impacto do Dodd-Frank, serão os Zumbis. E eles lideraram o trabalho sobre Sarbanes-Oxley há alguns anos. Amanhã é a reunião de refinamento. Eles estão atuando em apenas uma nova funcionalidade. Por que não reorientamos a reunião para incluí-los em uma discussão sobre Dodd-Frank, e logo depois, os convidamos a se concentrarem em tempo integral nele? Ariel, você está disponível? “

Ariel acena com a cabeça e eles concordam em se encontrar no dia seguinte com os Zumbis.

Refinando com os Zumbis

No dia seguinte, na reunião de refinamento com os Zumbis, Ariel explica a situação: “Vocês provavelmente já ouviram falar sobre Dodd-Frank. Mas aqui está a surpresa: Nós acabamos de ser informados pelos reguladores que eles querem que tomemos medidas ‘agora’ e demonstremos conformidade significativa até o final do ano. Caso contrário, eles podem restringir nossa negociação.”

Os zumbis ficaram visivelmente surpresos. Eles tinham ouvido rumores, mas não esperavam que teriam que correr contra o tempo! Tom disse: “OK Ariel, nos dê um rápido resumo do que isso significa. E como é diferente da Sarbanes-Oxley?”

Ariel pega uma caneta e começa a desenhar em um quadro branco. Após cerca de 45 minutos, ela conclui com uma visão geral e os Zumbis pareciam um pouco atordoados. “Fim do ano, eles disseram?”, disse Tom. “Mesmo se todo o grupo começar hoje, não iria terminar. Isso é enorme! “

Ele pega uma caneta e começa a desenhar um esboço de seu sistema no quadro branco, conversando com os outros Zumbis sobre o impacto que poderia ter. Ele disse: “Ariel, vamos também usar isso como uma chance de ajudá-la a entender melhor o sistema. Pergunte.” Ariel diz:” Você pode esperar um segundo? Deixe-me começar uma gravação de vídeo para me ajudar a lembrar disso.”

Simon, um veterano grisalho na equipe, diz: “É melhor começarmos logo com algum desenvolvimento real e aprendermos mais à medida em que progredimos, porque de outra forma acabaremos analisando para sempre. Já vi essa história antes.”

Alexandru, seu Scrum Master, disse: “Lembrei de algo … Tom DeMarco disse uma vez que a razão para cada projeto fracassado é que começou muito tarde.” Todos riem. Ele continua: “Bom, vamos passar o resto da sessão para encontrar uma área clara e “pegar um pedaço “ do Dodd-Frank. Vamos colocar as pertes maiores e menores em no nosso Product Backlog da Área.”

Mais tarde, Ariel conta a Peter o que eles fizeram na reunião de refinamento e sua recomendação por onde começar. Ela sabe que Peter e o resto da equipe de Product Owners decidirão o próximo passo.

Criando uma Nova Área de Requisitos

No dia seguinte, Ariel, Peter, e restante de Equipe de Product Owners se encontram. Ariel compartilha um resumo do escopo como ela entende agora. Peter suspira e diz: “Isso é ainda maior do que eu esperava. E os reguladores possuem o poder de nos derrubar agora. Eu não acho que eu preciso explicar o business case para mantê-los felizes o suficiente para que possamos manter a negociação.”

“OK!” Ele diz de repente e decididamente. “Precisamos de uma nova área para isso. Ariel, eu sei que você é nova entre nós, mas você acha que seria capaz de lidar com a responsabilidade de um Product Owner de Area por isso? “Ariel concorda.

Peter continua, “Rob você acha que os Zumbis poderiam trabalhar nisso? E precisamos deles para aprender mais sobre o Dodd-Frank e descobrir o impacto em nosso sistema antes que possamos adicionar mais equipes a isso. “Rob diz:” Eu não acho que tenhamos escolha”.

Peter diz: “OK Ariel, então agora temos alguns itens no Backlog da Área de Rob, o único item grande que você de “restante do Dodd-Frank “ e os itens menores que a equipe e você dividiram. Eu quero que você fale com Rob para te mostrar como configurar uma nova área no Product Backlog e mover os itens para ele.” Ariel sorri e diz: “Alexandru dos Zumbis chama os menores de nossa primeira mordida. “

Peter sorri de volta e diz, “A próxima Sprint começa em três dias. Vamos mover os Zumbis para a sua área e começar este monstro. Provavelmente em um conjunto de Sprints nós moveremos outra equipe para sua nova área. Senhoras e senhores, por favor pensem em qual equipe seria adequada? Agora, vamos terminar esta reunião e fazer alguma coisa! “

Planejamento de Sprint na Nova Área de Requisitos

Cada uma das áreas de requisitos conduz suas próprias reuniões do planeamento de Sprint, todas mais ou menos em paralelo. Na nova área de Ariel, ela inicia seu Planejamento de Sprint, introduzindo duas pessoas desconhecidas pelos Zumbis. Ela diz: “Gillian e Zak têm estado em contato com os reguladores frequentemente e nos ajudarão a fazer isso. Eles concordaram em nos ajudar agora no Planejamento, durante nossas sessões de PBR, e tanto quanto puderem diariamente nas próximas Sprints. “

Ela continua, “Aqui está o meu plano de ataque para as próximas duas Sprints. Primeiro, precisamos aprender mais sobre Dodd-Frank, e dividi-lo em algumas partes importantes e gerenciáveis ​​para que possamos começar a limpar o nevoeiro e obter um melhor senso de prioridades”.

“Em segundo lugar, vamos implementar um pedaço menor do que já implementamos anteriormente, iniciando esta Sprint. Isso nos dará uma melhor informação sobre o trabalho real. E teremos algum progresso concreto visível. “

“Terceiro, vamos nos preparar para mais equipes para se juntarem à nossa área.”

Tom toma a palavra de Ariel e compartilha com sua equipe, “Deixe-me explicar isso, porque eu representei nossa equipe na reunião do POT. Para começar, somos só nós. Vamos assumir a liderança no início da implementação, e obter o tamanho real do item, e compreender o impacto geral sobre a nossa arquitetura. “

Simon interrompe, “Como uma equipes de tigre trabalhando em um novo produto?” “Sim, assim mesmo”, diz Tom. “Pense no suporte da Dodd-Frank como um novo produto que precisa ser integrado ao resto do produto. Mas estamos com pressa, então em algumas Sprints outra equipe se juntará a nós e pouco depois, provavelmente mais duas equipes. Nós continuaremos desenvolvendo também, mas seremos a equipe líder, o que significa que precisamos levar as outras equipes a velocidade e garantir que mantenhamos o produto em mente “.

Simon diz: “Está começando a soar para mim como se nós fôssemos a equipe de arquitetura e gerenciamento de projeto.” Tom ri, “Não. Eu terminei com isso. Ainda somos uma equipe normal, mas, além do desenvolvimento, vamos nos concentrar em orientar e ensinar as novas equipes e manter um olho na integridade geral do sistema. Mas vamos ser claros: a coordenação e a gestão da equipe serão da responsabilidade de cada equipe “.

A Primeira Sprint na Nova Área de Requisitos

A primeira Sprint é incomum onde eles gastaram quase metade do seu tempo em refinamento, juntamente com Gillian e Zak, e apenas metade em desenvolvimento.

Mas a discussão e o aprendizado da codificação compensa. Lentamente começam a dividir o Dodd-Frank em partes que qualquer um deles possa entender. Parece que ninguém sabe o significado do todo.

Embora estivessem implementando o item pequeno que eles tinham selecionado em primeiro lugar, na maior parte do tempo eles estavam reunidos em quadros brancos para discutir as implicações gerais no sistema. Eles se alternavam frequentemente entre o código e a parede.

Revisão da Sprint na Nova Área de Requisitos

O grupo de produtos de Títulos trabalha em conjunto em uma Sprint, com um incremento lançável de produto. Mas cada uma das áreas de requisitos conduz sua própria revisão de Sprint, tudo mais ou menos em paralelo.

Na área de Ariel, durante sua Revisão, ela inspeciona e usa o item “pronto” que os Zumbis conseguiram completar e integrar no produto geral. Eles tinham a previsão original de entregar dois itens, mas Ariel está impressionada que eles ainda conseguiram um item pronto, dada a rapidez com que este novo trabalho foi lançado para eles.

A Segunda Sprint

Na segunda Sprint eles são capazes de fazer um progresso ligeiramente melhor em itens, embora eles mais uma vez gastam quase metade de seu tempo em refinamento, juntamente com Gillian e Zak.

No meio da Sprint, eles realizam uma sessão de PBR multiequipe com a segunda equipe que logo irá se juntar à área, ensinando-os sobre Dodd-Frank. E eles realizam uma oficina de design multiequipe para começarem a introduzir a equipe para a nova equipe o que eles mudaram até agora, e sua especulação para os próximos itens.

Os Zumbis sabem como o trabalho é grande e estão muito ansiosos para obterem mais ajuda.

Reunião da Equipe de Product Owners

Algumas Sprints depois …

É hora de mais uma reunião da Equipe de Product Owners para a Sprint. Eles utilizam esta reunião para alinhamento e coordenação entre os diferentes Product Owners de Área, e para Peter fornecer orientação geral.

Os Product Owners de Área compartilham, por sua vez, sua situação e os próximos objetivos. Quando chega a vez dela, Ariel diz: “Para nenhuma surpresa nossa, o progresso é pequeno e as surpresas são grandes. Mas a velocidade está começando a aumentar à medida que a névoa desaparece e as equipes e eu estamos mergulhando nossas cabeças dentro do trabalho. Gillian e Zak foram tremendos. “

Ravi, o Product Owner de Área de Serviços de Ativos, comenta alguns relacionamentos de itens próximos que ele agora vê entre suas áreas. Ariel faz uma anotação na página wiki do item e concorda em se reunir com Ravi e alguns representantes da equipe mais tarde.

Peter diz: “Ariel, sobre a nossa próxima Sprint. Quais são seus objetivos? “…

Adicionando uma Terceira Equipe

Algumas Sprints depois …

Na reunião de coordenação da Equipe de Product Owners, Peter diz: “Como você sabe, a área de Ariel ainda só tem duas equipes. Eu sei que Ravi gostaria de manter suas quatro equipes em serviço de ativos, mas Dodd-Frank é muito importante para mim este ano. Entăo vamos mudar uma equipe da área de Ravi para Ariel. Ravi, por favor, peça por uma equipe de voluntários de seu grupo e deixe cientes Ariel e eu. “

Multisite

Equipes Dispersas versus Equipes Multisites

Se todo o pequeno grupo de desenvolvimento é de oito pessoas em três países, há uma única “equipe” dispersa. (Nós não recomendamos isso, estamos definindo termos.) Mas quando seu único grupo de produtos é de 50 ou 500 pessoas, equipes dispersas não são necessárias; Cada equipe pode ser facilmente colocada literalmente na mesma mesa. No entanto, algumas equipes podem estar em sites diferentes, de modo que o grupo de produtos tenha equipes multisite.

História sobre LeSS Huge em Multisite

Ariel é a Product Owner de uma nova área de requisitos em um sistema de negociação de Valores Mobiliários. A nova área começou com apenas uma equipe, para manter foco e simplicidade. Mas Peter, o Product Owner geral, disse desde o início que, eventualmente, precisaria de pelo menos quatro equipes, dado o tamanho do trabalho. Depois de algumas Sprints, uma segunda equipe foi adicionada; A equipe original, os Zumbis Disléxicos, atuou como mentores para o segunda equipe.

Algumas Sprints mais tarde, a área de Ariel recebe uma terceira equipe. Mas ao contrário de suas duas primeiras equipes que estão localizadas em Londres com ela, sua terceira nova equipe, HouseDraculesti, está localizada em Cluj Romênia, em um importante local de desenvolvimento para a empresa.

Peter sabe que as equipes multisite são uma nova situação para Ariel, e ele a convida para uma reunião. Ele diz: “Oi Ariel. Eu queria compartilhar alguns conselhos sobre equipes multisite. Primeiro, peça ao seu Scrum Master para conversar com Sita e também peça que ela ensine alguns de seus eventos. Ela é uma Scrum Master na área de manutenção de ativos. Eles têm trabalhado com equipes multisite por quase dois anos, e ela terá um monte de sugestões. “

“Em segundo lugar, planeje para que você e toda a equipe Zumbis passem uma Sprint em Cluj o mais rapidamente possível. Trabalhe muito próxima a eles, todos em um sala. A equipe de Cluj poderia vir aqui para Londres, mas se você quer enviar um forte sinal de que eles são importantes, em seu site. Tente evitar fazê-los sentir que Londres é mais importante do que Cluj para o seu grupo. E você vai querer visitar lá regularmente. em seguida, …”

Planejamento de Sprint Multisite - Parte 1

Várias Sprints depois …

Ariel entra na sala. Há um projetor de computador conectado a um laptop Mac, exibindo um vídeo do Google Hangouts uma sala em Cluj. Os dois representantes da equipe nesse local estão sentados e esperando. Todos os representantes da equipe têm tablets ou laptops com eles.

Ariel diz: “Bem-vindos à Sprint Planning. Vamos começar. A minha oferta de itens desta Sprint está destacada na Planilha do Google. Vocês podem dar uma olhada? Ótimo. Por favor, insiram seus nomes de equipe ao lado dos itens que você desejam trabalhar. “

Feito isso, o grupo entra em uma fase de perguntas e respostas para encerrar questões pendentes sobre os itens - há sempre mais perguntas. Os representantes de Londres pegam algumas folhas do flip chart e começam a escrever perguntas. Os representantes do Cluj inserem suas perguntas em planilhas separadas em uma planilha do Google. Ariel passa algum tempo nos diferentes flip charts de papel, discutindo respostas e esboçando no papel. E ela passa algum tempo na planilha, digitando respostas para a equipe de Cluj, enquanto também conversa com eles cara a cara através da sessão de vídeo do Hangouts.

Após cerca de 30 minutos todas as perguntas foram respondidas, e Ariel pede a todos para sentarem. Ela diz: “Agora que passamos algum tempo separados, vamos convergir. Há alguma coisa que vocês aprenderam que vocês queiram compartilhar com os outros representantes da equipe, para ajudar nosso alinhamento ou coordenação? “

Quinze minutos depois, Ariel diz: “Feito! Eu vou ficar aqui no canto enquanto vocês discutem sobre coordenação e se preparam para a Parte Dois. “

PBR Multisite Geral

As pessoas estão vindo para a sala de oficinas em Londres. Dois projetores de computador estão ligados. Um deles mostra uma sessão de vídeo do Hangouts da sala de workshops em Cluj. O outro exibe um navegador no computador de Ariel.

Ariel diz: “Vamos começar. Eu quero me concentrar em dividir alguns dos nossos itens atuais e partes ainda menores. “

Usando uma ferramenta de gráficos de mapa mental no navegador, ela começa a criar algumas ramificações, enquanto discute com o grupo.

Depois, eles usam uma planilha do Google para discutirem um único exemplo para cada um dos novos itens divididos, de modo que os representantes em ambos os sites obtenham uma compreensão leve, mas concreta, dos detalhes.

Mais tarde, o grupo faz a estimativa dos novos itens, usando especialmente grandes cartas de “planning poker” que podem ser facilmente vistas através do Hangouts e das câmeras, conforme exibido nos projetores de computador.

Interações e Ferramentas Multisite

Conforme a história acima mostra, a interação “face a face” ainda é possível em um contexto de equipe multisite - e é vital! Ferramentas de colaboração modernas e gratuitas podem ser usadas de forma semelhante em uma Revisão de Sprint, Retrospectiva geral, e assim por diante.

Avante

Foco em todo o produto-Essas histórias dão uma sensação de aplicação do LeSS no contexto de uma Sprint e seus eventos. Embora não enfatizado, o princípio de foco em todo o produto no Less, é central em todas as histórias-todas as equipes juntas criando em comum um potencial incremento lançável de produto potencialmente entregue ao final de uma Sprint. Isso é realmente importante.

Organizações e Scrum falso—Também é importante que a estrutura organizacional permita tudo isso.

Scrum Escalado não é um framework especial escalado
que passa a utilizar “Scrum em cada equipe”

Scrum escalado é Scrum escalado.

É fácil criar grupos “falsos Scrum em Larga Escala” que estão aparentemente usando conceitos de Scrum, mas quando você traz a situação à tona você verá que a situação é basicamente a mesma que o antigo status quo, mas com o novo Scrum ou termos ágeis rotulado a frente. Desta forma, estes grandes grupos acabam com:

• A “equipe Scrum de análise” escrevem as histórias de usuários
• A “equipe Scrum de UX” entregam as histórias de wireframes de UX
• A “equipe Scrum de arquitetura” criam histórias no PowerPoint
• Muitas “equipes Scrum de programação” com seus respectivos “Product Backlog” em nível de equipe
• A “equipe Scrum de testes”

… todos a trabalhando seguindo a diretiz de “entregar o projeto até a data final; deixe-nos saber quando tudo estará” e conduzido por um falso Scrum Master gerente de projeto.

Isso tudo é uma porcaria.

Desta forma, uma vez que o verdadeiro Scrum em Larga escala começa com mudar a organização ao invés de mudar o Scrum, os próximos capítulos se concentrarão na estrutura organizacional LeSS e sua adoção.