Scrum e sistema de produção Toyota, construindo equipes poderosas

Segundo a Toyota, são os funcionários e não os sistemas que dão origem aos melhores produtos, pois não é possível fazer bons produtos sem desenvolver as habilidades dos funcionários. Para isso, a Toyota construiu um sistema de produção cujo objetivo é o desenvolvimento de funcionários excepcionais, chamado de Sistema de Produção Toyota (TPS).

Jeff Sutherland e Ken Schwaber confiaram parcialmente no TPS para construir a estrutura Scrum com o objetivo de desenvolvimento de produtos ou serviços complexos.

Scrum: a origem

As origens do Scrum podem ser rastreadas até um artigo de base publicado na Harvard Business Review em 1986 pelo Sr. Hirotaka Takeuchi, professor da Harvard Business School, e Sr. Ikojiru Nonaka, professor emérito da Universidade Hitotsubashi, sediada em Tóquio, intitulado The New New Product Development Games.

Em 1993, com base neste artigo e nos princípios da manufatura lean, Jeff Sutherland, desenvolve um método radicalmente diferente para o desenvolvimento de produtos no setor da informática. Em 1995, com a ajuda de Ken Schwaber, formalizou o método, criando assim o Scrum.

O Scrum é um método de planejamento rítmico, que se opõe à abordagem tradicional de lotes. Por exemplo, quando tratamos da construção de um sistema de computador, o planejamento rítmico diz que primeiro seja concluída a análise, para posteriormente prosseguir para o desenvolvimento e, sendo este finalizado, passar para a área de testes. Essa abordagem complicada e onerosa deixou diversos projetos travados.

O Scrum quebra esse modelo cortando a construção do produto em pequenos lotes chamados sprints. Durante um sprint, a equipe analisa, desenvolve e testa o que o cliente considera mais valioso. Um sprint dura entre 1 a 4 semanas. No final do sprint, durante sua revisão, é apresentado um incremento do produto ao cliente, que pode assim fornecer rapidamente um feedback. A equipe corrige e adapta o produto após cada sprint, de acordo com o feedback do cliente. Gradualmente, o produto ganha forma. Além dessa adaptação contínua às necessidades do cliente, o Scrum fornece uma estrutura formal para melhorar as práticas da equipe, introduzindo a noção de retrospectiva, que é um momento especial no final do sprint, durante o qual a equipe analisa as práticas para aprimorá-las no próximo.

Scrum, o Toyota Way e o Sistema Toyota de Produção

Se olharmos para o Scrum do ponto de vista do lean, fica claro que o método tem raízes no Toyota Way e no Sistema Toyota de Produção.

[Clique na imagem para ampliá-la]

Figura 1 - O caminho da Toyota

Do ponto de vista do Toyota Way, a melhoria contínua e o respeito pelas pessoas estão claramente representados. A própria estrutura do Scrum é semelhante a uma estrutura de solução de problemas que segue o ciclo PDCA (Planejar Fazer Checar Agir), conforme definido por Deming. Planejar com o planejamento de sprint, fazer através de sprint, o checar com a revisão de sprint e a demonstração ao cliente e agir com a retrospectiva. Esse ciclo de aprendizado é repetido continuamente durante toda a construção do produto e ajuda a entender as necessidades do cliente, o desenvolvimento individual e o trabalho em equipe.

O Scrum também se baseia em certos princípios do Sistema Toyota de Produção, especialmente no Gerenciamento Visual e o Just In Time. No final do cronograma do sprint, a equipe possui uma lista de pendências com histórias de usuários que visualizam por meio do gerenciamento visual Todo/Wip/Done ou Kanban. O desempenho da equipe é medido pela capacidade de entregar todas as histórias de usuários no final do sprint e analisado por meio de um gráfico de burndown. Cada sprint é um "Time Box" de um mês ou menos, durante o qual é criado um incremento de produto "Concluído", utilizável e potencialmente publicável (consulte o Guia Scrum em português). A construção do produto é dividida em pequenos lotes cuja entrega é programada em um ritmo constante; é o conceito do Takt encontrado no pilar Just In Time do TPS.

Nigel THURLOW, diretor ágil da Toyota Connected, demonstra isso de maneira brilhante no formidável treinamento Scrum The Toyota Way. No entanto, acreditamos que é possível ir ainda mais longe. Se o Scrum é uma ótima ferramenta de planejamento, também é, como Jeff Sutherland diz, um container para outras técnicas, métodos e práticas. Nesse sentido, uma estrutura perfeita para o desenvolvimento de pessoas sine qua non para a produção de produtos Wahoo. De fato, as diferentes experiências que conduzimos desde que descobrimos o lean em 2008 com Marie-Pia IGNACE e Michael BALLE mostram que uma implementação rigorosa do Sistema Toyota de Produção dentro do sprint traz resultados excepcionais em termos de aprendizado e uma produção fortiori.

[Clique na imagem para ampliá-la]

Figura 2 - O Sistema Toyota de Produção

A questão que surge é como implementar as ferramentas do Sistema Toyota de Produção para atingir cada incremento do produto, revelar em tempo real os obstáculos que a equipe enfrenta todos os dias e fornecer os meios para resolvê-los.

O TPS deve ser considerado uma pilar cujo objetivo é tornar os problemas visíveis no momento em que aparecem. Primeiro precisamos construir o sistema e depois fazê-lo funcionar:

1. Crie um bom gerenciamento visual;
2. Mantenha o fluxo;
3. Identifique os problemas corretos;
4. Resolva os problemas;
5. Desenhe as lições corretas.

Crie o gerenciamento visual correto

[Clique na imagem para ampliá-la]

Figura 3 - Exemplo de gerenciamento visual

Tudo começa nesta fase. É fundamental ter um bom gerenciamento visual para progredir e devemos distinguir o que está ok e o que não está. A equipe está entregando no ritmo e nível de qualidade corretos? A equipe gasta tempo corrigindo anomalias ou bugs? As histórias de usuários estão impedidas de aguardar informações de outras equipes ou da disponibilidade de um ambiente de teste? À primeira vista, deve ser possível verificar se a situação está sob controle ou não e se o desempenho geral da equipe está melhorando ou não. O bom gerenciamento visual deve incluir 4 painéis, um de clientes para capturar os incidentes, um de desempenho em relação a qualidade, tempo, custo, e indicadores de produtividade, um de produção e, finalmente, um dedicado à solução de problemas.

Mantenha o fluxo

A implementação do Just In Time dentro do sprint começa com o cálculo do Takt. Como o Scrum define o ritmo da construção do produto em um nível macro, é importante definir um ritmo de produção no sprint, para desenvolver histórias de usuários em um ritmo constante. O cálculo do Takt é simplesmente uma questão de dividir o número de histórias pelo número de dias úteis em um sprint: 20 histórias de usuário para um sprint de 10 dias geram uma taxa de entrega de 2 histórias de usuário por dia. Depois colocamos a produção no fluxo de entrega, ou seja, vamos ao final do processo e obtemos as histórias de usuários, como uma fila FIFO. O objetivo diário é definido pelo Takt. Em nosso exemplo, a equipe escolheu duas histórias de usuário, começando pelas localizadas no estágio mais próximo da produção. A equipe se compromete diariamente com uma meta de produção, que nesse caso é 2 histórias de usuário, selecionadas dentre as mais antigas. Se a equipe alcança o objetivo, perfeito. Se isso não acontece, melhor ainda, há algo a aprender, é uma nova oportunidade para melhorar e, assim, usar o kaizen.

Identifique os problemas corretos

Veja os problemas de qualidade

Se o princípio de quebra em pequenos lotes é bem explorado pelo Scrum, o Jidoka, o segundo pilar do TPS é bem menos. O Jidoka trata de introduzir qualidade no processo, para que não propague problemas de qualidade ao longo do processo até o cliente. Várias técnicas, como parada no primeiro defeito, autonomação, sinais vermelhos e outras, permitem descobrir problemas de falta de qualidade antes que se espalhem na produção e penalizem os usuários da aplicação ou serviço.

As equipes mais avançadas usam técnicas extremas de programação, como Desenvolvimento Orientado a Testes (TDD) e Integração Contínua (CI), para implementar partes do Jidoka. Porém, nem todas as equipes têm o nível de competência necessário para implementar as técnicas que, por sua vez, não cobrem todo o processo. A questão que se coloca aqui é, como identificar problemas de qualidade no processo, independentemente do nível de domínio dessas práticas? Uma resposta possível é a introdução, em todas as etapas do processo de produção, da técnica lean de sinais vermelhos.

[Clique na imagem para ampliá-la]

Figura 4 - Veja os problemas de qualidade

Sempre que um problema de qualidade é descoberto em um estágio do processo, as informações são armazenadas na coluna de sinal vermelho. A análise rigorosa e sistemática do conteúdo permite que a equipe entenda melhor o que está bloqueando o fluxo, desencadeando ações imediatas para proteger o cliente e a solução de problemas necessária a longo prazo para remover permanentemente esses obstáculos.

Figura 5 - Exemplo de coluna de sinal vermelho

Veja os problemas no fluxo

O uso do fluxo de entrega destaca uma série de problemas relacionados à dinâmica do processo de desenvolvimento: problemas de sobrecarga e superprodução ou sincronização com outros processos, como mostra a figura abaixo.

[Clique na imagem para ampliá-la]

Figura 6 - Veja os problemas no fluxo

Solução dos problemas

O único objetivo do que foi descrito acima é criar um pilar para destacar o que a equipe não consegue controlar. Assim, a implementação do fluxo de trabalho e do Jidoka revelará por meio do gerenciamento visual diferentes fontes de problemas:

• Problemas de qualidade encontrados nas colunas de sinais vermelhos e que são principalmente uma expressão de falta de habilidades;

• Sincronização com outros fluxos quando histórias de usuário estão pendentes na coluna de trabalho em andamento;
• Problemas de superprodução ou sobrecarga quando histórias de usuários se acumulam em uma coluna pronta ou em execução.

Ao tornar esses obstáculos visíveis em tempo real, a equipe possui loops de feedback muito curtos que permitem reagir com extrema rapidez para colocar as histórias de usuários com defeito de volta ao fluxo (correção = proteção do cliente). A equipe pode dar um passo atrás para lidar definitivamente com o problema (resolução = eliminação permanente do problema). Para fazer isso, o lean defende uma abordagem científica para a solução de problemas com o PDCA (Plan Do Check Act).

[Clique na imagem para ampliá-la]

Figura 7 - Exemplo de PDCA

O ponto principal do método reside no acúmulo de oportunidades de aprendizado e em um processo consciente de solução de problemas. Os colaboradores não obtêm sucesso por coincidência, mas por uma análise sistemática dos problemas, pela busca de causas-raiz, pela implementação de contramedidas adequadas, pelos testes e por uma capitalização do que a equipe aprendeu. Essa atividade repetida é como se fosse um catalisador do desempenho individual e coletivo. O tratamento de sinais vermelhos permite identificar com precisão as causas dos problemas de qualidade que frequentemente são causados por problemas de habilidade. Esta é uma oportunidade para o Scrum Master ou o Líder da equipe configurar as matrizes de habilidades e dojos de treinamento para trabalharem em questões específicas, como escrever histórias de usuários mais relevantes ou um código mais limpo.

Figura 8 - Exemplo de matriz de competências

A análise do fluxo, da superprodução e do tempo de espera fornece uma melhor compreensão das adesões de projetos ou produtos com o restante do ecossistema. Os membros da equipe criam uma colaboração intensiva não apenas dentro da equipe, mas mais importante ainda com os colegas, trabalhando em tópicos relacionados. A solução de problemas não é mais um assunto individual, mas uma questão de equipes em sentido amplo. Pouco a pouco, toda a organização funciona melhor. Os processos são simplificados à medida que as melhorias são feitas coletivamente.

Os resultados

Nas 20 equipes observadas, que aplicaram a metodologia, observamos uma melhoria muito significativa no desempenho.

Melhorando a qualidade da produção

Assim, no campo da qualidade, os estoques de incidentes não processados diminuíram, em média, 59%. Ao mesmo tempo, o volume de novos incidentes caiu 37%. Isso resultou em um aumento médio na satisfação do cliente de 25%.

Figura 9 - Melhoria da qualidade

Aceleração da produção de valor

Seja na resolução de incidentes, no desenvolvimento de pequenas mudanças ou na realização de novas histórias de usuários, a aceleração também é notável. O lead time é dividido em média por 6,5 e a produção é multiplicada por 3.

Figura 10 - Aceleração da produção de valor

Impacto econômico

Por exemplo, em uma unidade de negócios de 40 pessoas, o equivalente a 5 funcionários é responsável pela correção de incidentes. Numa base experimental, o gerente decide criar uma equipe dedicada à redução de incidentes. Em 6 meses, essa nova equipe, graças à implementação do TPS, erradica os incidentes e passa de um estoque permanente de 80 incidentes e um volume diário de 3 novos incidentes para um estoque de 0 e um volume mensal de 2 novos incidentes. O custo da resolução de incidentes diminui. Passa de 720.000 euros por ano a 0 euros (5 pessoas * 600 euros * 240 dias). Em seis meses, o gerente ganhou mais de meio milhão de euros vindos do orçamento RUN (sem contar as economias provocadas pela melhoria da qualidade) que podem ser realocados para valorizar a produção. Esse ganho de produtividade permite acelerar o processamento do backlog de pequenas alterações e, assim, produzir mais valor para os clientes.

Conclusão

O objetivo do sistema de gerenciamento lean é desenvolver funcionários excelentes para produzir produtos excepcionais. O Sistema de Produção da Toyota, TPS, é um conjunto de práticas cujo único objetivo é destacar as fraquezas do processo, para que os funcionários possam resolvê-las desenvolvendo mais habilidades. O Scrum é a implementação do Just In Time para produção de sistemas de computadores. O método de cadência da construção do sistema por meio de uma série de incrementos que têm a forma de PDCA: Planejar o sprint, Executar o sprint, Verificar a revisão do sprint e Atuar na retrospectiva.

No entanto, a aplicação do TPS não deve parar por aí. Em cada etapa do processo, os funcionários podem progredir individual ou coletivamente em toda a cadeia de produção, seja o dono do produto (PO), os desenvolvedores, os arquitetos ou mesmo os testadores. Portanto, é fundamental que o desenvolvimento de todos resulte em um sistema que revele problemas onde surgem, em tempo real, para lhes dar a oportunidade de melhorar a situação, suas habilidades, o processo ou a interação entre diferentes serviços.

O TPS oferece as ferramentas necessárias para isso:

• O gerenciamento visual na condição em que mostra as diferentes etapas do processo;
• O fluxo de entrega que dá um ritmo à produção e permite feedback imediato sobre a capacidade de cumprir prazos;
• Os sinais vermelhos que fornecem feedback imediato sobre a qualidade do que é produzido.

Com esse sistema, as equipes se concentram nos problemas operacionais que os impedem de atingir a meta diária. Os membros da equipe desenvolvem as habilidades, resolvem problemas após problemas, graças a um rigoroso método de análise científica. Cada PDCA os aproxima de um ideal de produção, no qual todas as histórias de usuários passam sem problemas do processo de fabricação até a produção. A implementação do Jidoka revela problemas de qualidade que geralmente estão relacionados a problemas de habilidade. O Just In Time mostra os problemas de fluxo e as aderências com o restante do sistema, o que desencadeia a solução de problemas entre as equipes.

Pouco a pouco, as histórias de usuários são melhor descritas, o tamanho começa a diminuir, os desenvolvedores produzem um código de melhor qualidade, mais sustentável, mais robusto e mais confiável. Os integradores encontram menos defeitos e têm mais tempo para se concentrar em testes ou automação de limites. O trabalho colaborativo com outras equipes simplifica o sistema e otimiza as trocas. A equipe desenvolve novas habilidades e adota novas práticas. A capacidade da equipe aumenta à medida que a qualidade melhora, a produção acelera e os custos diminuem. O cliente fica feliz.

Sobre o autor

Pierre Jannez é um coach de Lean IT Senior especializado em melhorar o desempenho das equipes de TI. Está interessado em práticas ágeis desde 2001 e as implantou por dez anos na Nokia e na Nokia Siemens Networks dentro da equipe de desenvolvimento francesa, utilizando os métodos: programação extrema, TDD, integração contínua, BDD, entrega contínua e Scrum. Em 2008, ele e a equipe descobrem o lean. As primeiras aplicações fornecem resultados imediatos, qualidade e prazos melhoram significativamente. Desde 2010, se dedica à aplicação do Sistema Toyota de Produção na área de TI na empresa Operae Partners.