Lean Thinking IT — The power of small batches approach.

The power of small batches

A abordagem small batches, ou fluxo de uma peça só, não é uma novidade. Trata-se de um método de produção criado, logo após a segunda guerra mundial, pela fabricante japonesa Toyota. Muitas referências indicam que esse foi um dos fatores de sucesso que corroboraram para que a Toyota se tornasse a maior fabricante de carros do mundo.

Os métodos ágeis, entre eles Scrum, XP, Kanban e lean software development, transformaram a engenharia de software na última década. O artigo em questão, apresenta especificamente o poder potencial de transformação da abordagem Small Batches, quando aplicada em equipes ágeis em qualquer um dos métodos ou frameworks citados.

A literatura apresenta grandes obras sobre o assunto, o conceito recentemente foi tratado com maestria em duas obras A Mentalidade Enxuta nas Empresasde James Womack e Daniel Jones e A Startup Enxuta de Eric Ries.

Referências sobre small batches

James e Daniel apresentam a célebre história da competição de um pai com suas duas filhas. O desafio tratava-se de preparar, no menor tempo, o maior número de cartas a serem postadas pelo correio. Cada um dos competidores recebeu o mesmo número de cartas.

As duas filhas optaram por utilizar a produção em série. Seguindo essa abordagem primeiro elas dobravam todas as cartas, após inseriam todas as cartas nos envelopes, na sequência fechavam e colavam todos os envelopes, por final endereçaram e selavam os envelopes. Por sua vez o pai resolveu utilizar a abordagem de um envelope por vez, ou seja small batches approach. Partindo desse princípio o pai só iniciava a confecção de nova carta após a carta em produção estar completamente pronta.

Surpreendentemente o pai ganhou a aposta. No livro A Start Up Enxuta, Ries apresenta motivos pelos quais essa abordagem é mais eficiente e eficaz do que a produção em massa. Entre os motivos estão desperdício de tempo para classificar, empilhar e deslocar um grande número de envelopes semi completos. Ries em sua obra expende sobre maneiras as quais essa abordagem pode ser utilizada em ambientes empresariais, tendo como objetivo evitar desperdícios e aumentar a qualidade do produto final.

A própria Toyota, como já referido, foi uma grande beneficiária desse método de produção. Após a Segunda Guerra Mundial, a economia e a indústria japonesa estavam em situação deplorável. A Toyota buscou uma forma minimalista de trabalho para competir com as imensas fábricas americanas, altamente adeptas à produção em massa. Existem diversos estudos comprovando eficácia dessa metodologia, um dos mais famosos é o One Piece Flow versus Mass Production de Ron Pereira. No vídeo o autor cronometra cada etapa do processo em massa e contabiliza em segundos o tempo de desperdício.

Small Batches no mercado de TI

O mercado de desenvolvimento de software vem passando por diversas transformações recentes e, devido a isso, apresenta-se como um ótimo campo de estudo para tratar sobre Small Batches. A aderência cada vez maior, por parte das empresas, aos métodos ágeis reduziu de forma drástica o tempo de entrega de cada etapa de um projeto. Um dos pilares das metodologias ágeis trata-se exatamente de realizar pequenas entregas, incrementais em um curto espaço de tempo, porém com alto valor agregado.

A partir dessa constatação surge a pergunta: Seguir métodos ágeis realizando entregas sequenciais de curto prazo é igual a utilizar a abordagem small batches? Não, definitivamente não é.

Atuo no mercado de TI a mais de 15 anos, e é incontável o número de relatos que ouvi sobre tarefas relativas uma história de usuário que eventualmente duram uma Sprint ou mais para serem realizadas e que, além disso, são executadas por mais de um profissional.

O Sistema Lean Manufacturing, quando trata de Fluxo de uma peça, é bem claro quanto à definição: uma unidade de trabalho entrega um produto completo por vez. Trazendo isso para a realidade de desenvolvimento de software, uma tarefa deve possuir apenas um colaborador como responsável (no máximo dois, exclusivamente em caso de pair programming). Além disso, a atividade deve ter duração breve, não pode ter a duração semelhante ao tempo de uma sprint. Um dos principais argumentos para essa regra existir é que, quanto mais cedo os problemas de qualidade vierem a tona, mais fácil e rápido será de corrigi-los. Os Japoneses são fantásticos, o sistema Lean Manufacturing possui uma ferramenta de gestão visual chamada Andon, que tem por objetivo comunicar o máximo de número de funcionários na fábrica quando as anormalidades ocorrem. Saiba mais sobre Andon, artigo Como Operar um “andon” no site Lean Institute Brasil.

Small Batches na prática

Já faz quase um ano que atuo em um projeto ágil (Scrum), o cliente é uma grande multinacional e o desenvolvimento é realizado por um time internacionalmente distribuído. Durante as primeiras Sprints, haviam algumas situações em que as tarefas ocupavam uma semana ou mais e algumas tarefas eram executadas por mais de um colaborador. Existia a preocupação em quebrar as tarefas, mas não existia uma regra clara e nem uma iniciativa incisiva para trabalhar com small batches.

As retrospectivas desse projeto eram ótimas, foram identificados pontos de melhoria e problemas a serem resolvidos, entre eles:

  • Tarefas extensas resultavam em baixa interação entre colaboradores;
  • Devido a baixa interação, as Daily Meetings acabavam por apresentar colaboradores com baixo interesse, participação e engajamento;
  • Tarefas grandes fazem com que seja mais morosa a identificação de problemas de qualidade, assim como o eventual atraso;
  • Tarefas sequenciais, que possuam mais de um colaborador envolvido, criam desperdício devido à dependência (a única exceção a esse postulado seria a utilização de pair programming, que é uma abordagem altamente recomendada);
  • Tarefas extensas induzem determinadas pessoas a acumular conhecimento sobre assuntos específicos;

Identificada à causa raiz, foi formulada a regra extremamente clara com duas diretrizes:

  • Cada tarefa será executada por um colaborador;
  • Cada tarefa terá no máximo um dia de duração;

É impressionante como a aplicação de small batches tem efeito imediato, e isso faz todo o sentido, pois, os principais desperdícios são eliminados imediatamente. abaixo a listagem de pontos de melhoria que ficaram evidentes já após a primeira Sprint rodada com small batches:

  • Interação maior entre todos os membros da Equipe;
  • Maior disseminação de conhecimento no time;
  • Rápida identificação e solução de problemas de qualidade;
  • Redução drástica na quantidade de defeitos encontrados pela equipe de qualidade;
  • Maior engajamento do time nas cerimônias Scrum;
  • Uma série de entregas de Sprints com sucesso e reconhecimento por parte do cliente final;
  • Empoderamento das pessoas com relação às suas responsabilidades quanto ao sucesso da Sprint;

O início da operação com Small Batches nem sempre é simples. No caso histórico da Lean Manufacturing, a Toyota contava com alguns engenheiros geniais como o Taiichi Ohno e Shigeo Shingo que revolucionaram os métodos de produção, daquela época, ao projetarem máquinas que produziam uma grande variedade de peças em pequenos lotes. Criaram com esse objetivo a Troca Rápida.

A notícia boa é que para o mercado de desenvolvimento de software, existem diversas ferramentas e frameworks que auxiliam a suportar uma operação de small batches entre elas:

  • Testes Automatizados
  • Testes de Integração
  • Ferramenta de Integração Contínua
  • Versionadores de códigos seguros e com boa capacidade de integração entre códigos de diferentes desenvolvedores
  • Ferramentas de Gestão Visual ( VSTS, Gira, Trello)

Making Of

Após a migração para a abordagem de Small Batches, o que mais me impressionou está relacionado a um ponto que não é explorado na literatura vigente sobre o tema: A mudança de comportamento das pessoas.

O crescimento do time como um todo, com relação conceito de “Equipes autogerenciadas”, foi marcante. O empoderamento de cada um dos membros do time foi imediato, todos passaram a sentir-se “donos” do projeto e responsáveis pelo sucesso da Sprint. Somado a isso, a solidariedade do time visando resolver impedimentos ou solucionar dúvidas técnicas de seus pares passou a ser cada vez maior. Um dos principais resultados de tudo isso é a atenção crescente do time com relação à qualidade do projeto, o que gera um produto superior.

Fica claro que o caminho em direção à abordagem small batches nem sempre será tranquilo, um projeto de software precisa estar muito bem estruturado com relação a sua arquitetura. O mesmo deve ser projetado, desde o inicio, visando suportar um ambiente extremamente dinâmico. Sempre haverá algum questionador com relação aos argumentos para se utilizar essa abordagem. Isso ocorrerá porque, intuitivamente, small batches não aparenta ser a forma mais eficiente para atingir resultados superiores. Entretanto, ser um agente ativo em uma transformação desse nível é uma experiência ímpar e deveras prazerosa. Verificar os resultados em um espaço de tempo de semanas já é fantástico, agora perceber a mudança de comportamento das pessoas é surreal. Recomendo fortemente essa jornada a todos que vislumbrarem uma oportunidade, todos têm a ganhar.

English EN Portuguese PT Spanish ES
 

3 comentários em “Lean Thinking IT — The power of small batches approach.

  • O artigo é muito bom e retrata bem a realidade em termos de mudança de postura da equipe a partir da redução do tamanho das tarefas e do sucesso nas entregas das Sprints. Fundamental registrar que no modelo Scrum o engajamento da equipe é essencial para o sucesso da entrega, pois considerando o fato de que cada membro da equipe é uma peça da engrenagem, esta só irá rodar corretamente se todas as peças estiverem alinhadas e conectadas. Abs

     
    • Ótimo comentário Rodrigo Sander, o engajamento é realmente fundamental na execução do Scrum. A mudança na forma de trabalhar exige energia e flexibilidade para sair da zona de conforto e iniciar um ciclo de melhoria contínua.

       

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *