BT

A sua opinião é importante! Por favor preencha a pesquisa do InfoQ!

O Ágil na LEGO

| por Ben Linders Seguir 12 Seguidores , traduzido por Eduardo Kuwakino Seguir 0 Seguidores em 08 nov 2017. Tempo estimado de leitura: 7 minutos |

O Ágil é parte da LEGO há mais de uma década, mas continua semeando e encontrando aplicações nas áreas de negócios além das áreas digitais e de TI. Alguns dos principais valores da LEGO são brincar e aprender que combinam bem com os princípios ágeis de iterações, experimentação e retrospectivas.

Eik Thyrsted Brandsgård, diretor na agência interna de marketing da LEGO, discursou sobre algumas das práticas ágeis que a LEGO experimentou na Agile Summit Greece 2017. O InfoQ cobriu essa conferência com perguntas e respostas, resumos, e artigos.

O InfoQ entrevistou Eik Thyrsted Brandsgård que tem participado da jornada ágil da LEGO com o objetivo de descobrir mais sobre esta jornada.

InfoQ: O quê fez a LEGO decidir a adotar o ágil?

Eik Thyrsted Brandsgård: Quando entrei na LEGO em 2005, o ágil já estava presente em pequena escala, por meio do XP - tínhamos desenvolvedores que faziam pair programming. O conhecimento sobre ágil foi lentamente se espalhando e ganhou tração de verdade por volta de 2009 quando as equipes que desenvolveram o LEGO Universe (um Massively Multiplayer Online Game) foram certificadas em Scrum pelo Ken Rubin. Quando o LEGO Universe acabou anos depois, as práticas ágeis estavam inseridas no braço digital da LEGO. Alguém vindo do LEGO Universe parecia como se tivesse vindo do Tour de France, com pernas realmente boas. Algumas das equipes daquela época continuam intactas e trabalhando muito bem.

Mantivemos recrutando e treinando pessoas em ágil mas como a LEGO cresceu tivemos alguns problemas no crescimento (conhecido como aumento de complexidade) e em 2014 decidimos usar SAFe como ponto de partida para escalar o ágil. Pelos anos seguintes ajustamos o método e continuamente identificamos e removemos interdependências e eventualmente nos organizamos para reduzir um pouco da complexidade e limitações e encolhemos novamente para uma configuração baseada em scrum.

InfoQ: Quais adaptações foram realizadas para que o SAFe melhor atendesse a LEGO?

Eik Thyrsted Brandsgård: O framework é bem compreensivo, praticamente um guia abrangente do ágil. Uma vez que começamos com Scrum, a escolha óbvia parecia construir a próxima camada sobre o Scrum - a camada do programa. A parte de gestão de portfólio nos níveis mais altos continua rodando como um processo anual de toda a empresa, seguindo um ciclo de planejamento financeiro regular. Continuamos perseguindo tornar esse processo mais ágil, porém é uma mudança muito grande. E descobrimos que podemos trabalhar partes do SAFe em um modelo de operação mais tradicional.

No nível de "equipe de equipes" (team of teams) paramos de apresentar todos os planos das equipes para todos e criamos um "plano justo" (plan fair) em que as equipes podem decidir se ouvem os outros planos. Nem todos os planos são relevantes a todo mundo, então permitimos que as equipes escolham o que acham mais relevante.

Removemos temas e recursos da parede do programa e mudamos para apenas um quadro de dependência. Descobrimos que as equipes não são muito interessadas em cada um dos outros trabalhos das equipes, apenas nas interdependências entre equipes. Portanto tendo temas ali criou-se mais confusão do que contribuição à transparência.

Também paramos o voto de confiança, havia muita confusão no que significava confiança - sua própria equipe? O todo? É uma ferramenta muito útil numa escala pequena, mas as dinâmicas são diferentes em grandes grupos com centenas de pessoas.

Jogamos a responsabilidade pelo risco de gerenciamento ROAM (Resolve, Own, Accept, Mitigate) para próximo das equipes e pedimos a elas para trazer sugestões de mitigação e com isto, empoderamos as equipes a realizar suas próprias ações, movendo-as para cima na escada da responsabilidade. Dessa forma apenas os riscos mais difíceis tem de ser discutidos na revisão de gerenciamento (management review).

Também experimentamos conversas inspiradoras de centro palco uma vez que juntamos tantas pessoas mas descobrimos que isso tira muito foco do planejamento. Eventualmente cortamos desperdícios baseados nos feedbacks dos participantes e agora podemos planejar o todo em um único dia para o deleite de todos. Shu-Ha-Ri.

InfoQ: Como é feito o big room planning na LEGO?

Eik Thyrsted Brandsgård: Em uma resposta curta: colocamos 150 pessoas em uma sala enorme e não deixamos elas saírem até terem criado um plano para os próximos 2 meses (risos). Bem, esse é o ápice. O processo é muito parecido com o Scrum, mas em escala. Começamos com alguns planejamentos preliminares. Identificamos o trabalho que queremos priorizar na perspectiva de negócios. Esse trabalho é estimado grosseiramente e quebrado um pouco para identificar os maiores elementos técnicos. Este é o backlog com o qual iniciamos o big room planning, depois as equipes pegam o trabalho e dividem e estimam da maneira scrum. Quando a equipe termina um dos itens do backlog compartilhado, eles pegam o próximo até esgotarem sua capacidade estimada.

Em algum momento do big room planning as equipes apresentam seus planos preliminares e ajustes são feitos se necessários - remoção de impedimentos, mitigação de riscos, repriorização, movimentação de trabalho para outras equipes com o fim de criar um fluxo.

InfoQ: Quais benefícios a LEGO teve ao fazer os big room planning?

Eik Thyrsted Brandsgård: Esses são alguns dos benefícios que tivemos:

  • Rápida tomada de decisão

Todas as equipes, decisores, e principais stakeholders envolvidos em trazer o produto ao mercado estão na sala. Então é rápido compartilhar informações e tomar decisões.

  • Transparência

Fica muito claro o que é necessário para preencher as necessidades de negócios. Às vezes ideias que parecem fáceis são bem difíceis de realizar e vice-versa. Como um stakeholder você pode ver isso em primeira mão - ninguém está tentando esconder a complexidade ou amenizar; é o que é.

  • Empoderamento

As equipes são as únicas que podem realmente planejar e estimar como completar um trabalho e os stakeholders podem tomar decisões imediatamente. Isso cria um ciclo de feedback rápido que empodera ambos, a equipe e seus stakeholders para tomar as decisões de negócios de maior valor.

  • Identifica dependências e complexidade

O quadro de dependência realmente mostra onde as equipes dependem uma das outras. Ele também visualiza a complexidade geral e se um padrão emerge há uma oportunidade de remover um pouco da complexidade.

  • Socialização

Com tantas pessoas se reunindo de uma vez pode ser visto como uma grande equipe realizando um evento. Há muitas conversas rolando e as pessoas realizam mais de uma atividade, discutem negócios e fortalecem seu networking.

InfoQ: O que você aprendeu com a forma com que o ágil tem sido escalado na LEGO?

Eik Thyrsted Brandsgård: Um método bem descrito como o SAFe é um excelente ponto de partida para escalar o ágil, mas conforme as organizações aprendem, é importante tentar e experimentar e encontrar seu próprio caminho. Use as metodologias ágeis verdadeiramente, construa ciclos de feedback e rapidamente terá viradas e mudanças no sentido de reduzir desperdícios no processo, e isso se torna muito aparente quando temos 150 pessoas perdendo energia e é o que as empolga - o que realmente valorizam. Isso facilita orquestrar 150 pessoas, é muito mais uma big band de jazz do que uma orquestra, mas ainda exige facilitação para correr bem - tanto durante o big room planning quanto fora dele.

O ágil é um tema em alta no momento, toda empresa no mundo quer ser mais rápida e veloz e estar preparada para "disrupção". Mas o ágil não é uma bala de prata, ele tem sua hora e lugar. Porém quando há muitas incertezas e mudanças constantes e o desenvolvimento e inovação caminham lado a lado, o ágil pode realmente brilhar. E acredito que há ainda algumas áreas na LEGO onde podemos continuar aplicando ágil tendo bons resultados para continuar aprofundando e experimentando.

Também aprendi a apreciar o termo "não se prepare, comece". Inicialmente eu estava hesitante e queria me preparar muito bem, mas realmente acredito que se as pessoas na organização são curiosas o suficiente a tentar o ágil, vá nessa. Peça ajuda de pessoas experientes para começar, mas tenha confiança de que ciclos de feedback criados internamente e iterações rápidas farão você aprender mais rápido. É um pouco como quando uma criança anda de bicicleta pela primeira vez - inicialmente ela fará uma volta instável, mas rapidamente as rodas equilibram a bicicleta e a criança se sente no controle, aumenta a velocidade, e a jornada começa.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT