O jeito Toyota para Scrum

O projeto Toyota Connected utiliza Scrum combinado com o Sistema Toyota de Produção para executar a Produção Lean, possibilitando que times entreguem ciclos de PDCA rápidos. Scrum de Scrums, Meta Scrum e o CPO (Chief Product Owner) são algumas das abordagens utilizadas para escalar o Scrum em múltiplos times e produtos. A agilidade não é o objetivo, é uma consequência.

Nigel Thurlow, líder de agilidade no projeto Toyota Connected, falou sobre "O jeito Toyota para Scrum" na eXperience Agile 2018. A conferência aconteceu em Portugal, nos dias 1 e 2 de Outubro e o InfoQ cobriu o evento com perguntas e respostas, resumos e artigos. O tema da conferência neste ano foi "Melhorar através das pessoas", como descrito abaixo:

Conteúdo relacionado de patrocinadores

Descubra as últimas novidades sobre práticas Ágeis com líderes de indústrias de todo o mundo. O eXperience Agile é mais do que uma simples conferência Ágil, é um evento que vai realçar as aplicações Ágeis mais revolucionárias atualmente em uso.

Na entrevista concedida ao InfoQ, Thurlow falou sobre como o DNA da Toyota se conecta com Ágil e Scrum, os desafios que o Toyota Connected vem enfrentando, como aplicam agilidade e como aprendem, qual o papel do Product Owner, como a suíte C se comporta no mundo Ágil e como Ágil e Scrum se relacionam com o Sistema Toyota de Produção e Produção Lean.

InfoQ: Qual o DNA da Toyota e como está conectado com o Ágil e Scrum?

Nigel Thurlow: Todos na Toyota compreendem a ideia de cliente em primeiro lugar e os princípios fundamentais sobre o Sistema Toyota de Produção e o jeito Toyota. Quando discutimos o valor da adoção de uma nova tecnologia e do mundo digital, sempre temos nosso DNA como referência do porquê precisamos fazer aquilo: nossos clientes.

A ideia de cliente em primeiro lugar apareceu pela primeira vez em 1946, pelo presidente da Toyota Motor Sales do Japão, Shotaro Kamiya. Significa o princípio de considerar as necessidades e desejos do cliente ao determinar a direção e a estratégia. Uma vez estabelecido, entrega a mais alta qualidade no menor ciclo de tempo e com o menor custo.

O Scrum é um framework que permite que os times entreguem ciclos de PDCA rápidos, onde o valor é priorizado pelo cliente e o trabalho sem valor é descartado. É importante notar que o Scrum não te faz Lean, e ser Lean também não significa que está fazendo um excelente Scrum.

A agilidade é um resultado ou uma consequência e o Scrum é apenas um caminho para alcançá-la, e de fato é o melhor caminho para codificar PDCA que já trabalhei. Todos sabem o que é o PDCA, mas ninguém sabe por quanto tempo o ciclo de PDCA deve se estender. O que estamos tentando fazer com Scrum é encurtar o ciclo de inspecionar o feedback do cliente (checar) e adaptar para aquele feedback (agir). Às vezes chamo isso de PDIA (Plan, Do, Inspect, Adapt).

Somente o Scrum não te faz Lean, e ser Lean também não significa que é Ágil. É possível ser Lean sem ser Ágil e ser Ágil sem ser Lean. São coisas diferentes, ainda que conceitos complementares. Queremos ser Lean entregando um fluxo de valor da forma mais eficiente possível, mas também queremos ser Ágeis estando aptos a responder rapidamente às mudanças de demandas do cliente/mercado ou a eventos desconhecidos.

InfoQ: Quais são os desafios que o Toyota Connected vem enfrentando?

Thurlow: O Toyota Connected (TC) é um projeto fundado como uma startup Ágil para ajudar a Toyota a responder rapidamente às mudanças da área de tecnologia de carros conectados. Não estamos falando apenas sobre carros autoconscientes, mas sobre prover um leque de serviços conectados para os donos de veículos e suas necessidades de mobilidade. É a visão do presidente da Toyota, Akio Toyoda, que tentamos executar quando fomentamos as ferramentas digitais que temos à nossa disposição - da Inteligência Artificial à Internet das Coisas - possibilitando-nos a construir o futuro da tecnologia dos veículos conectados.

Trabalhamos em um mundo com mudanças frenéticas, onde o tempo de lançamento do produto no mercado não é mais medido em anos, mas em meses e, em breve, períodos ainda menores. Uma vez que a habilidade para atualizar carros em tempo real transforme-se em uma ocorrência diária, os níveis crescentes de dados disponibilizados em tempo real estarão disponíveis para stream. Devemos ser capazes de entregar os benefícios e as capacidades que nossos clientes buscam.

Isso está ajudando uma empresa de seguros a definir taxas através de uma pontuação precisa e significativa do motorista, possibilitando a correção de um problema operacional com uma atualização online para criar opções de mobilidade - como o serviço de carros compartilhados Hui em Honolulu - Havaí, em parceria com a Servco Pacific Inc- , integrar a Alexa da Amazon nos veículos da Toyota, e estudar avanços na ciência de dados e IA.

InfoQ: Como o Toyota Connected aplica o Ágil?

Thurlow: Praticamos e ensinamos o Sistema Toyota de Produção (Lean) e os princípios do jeito Toyota, mas também somos uma empresa Ágil por padrão. O projeto TC foi organizado para se comportar como uma startup, mas com estabilidade e fundos de uma empresa global. Criamos um ambiente de trabalho para estimular engenharia boa e excelência técnica, permitindo que os times se desenvolvam de forma aberta e criativa.

Nossos times colaborativos são pequenos (normalmente de cinco a seis pessoas) e se sentam bem próximos em um espaço colaborativo com salas de guerra, gerenciamento visual e displays informando a qualidade do projeto ao redor da equipe. Enquanto utilizamos ferramentas eletrônicas, ensinamos e encorajamos o gerenciamento visual possibilitando a transparência, abertura e possibilidade para conversas em tempo real com líderes e stakeholders ali mesmo, no chão de fábrica.

Focamos na criação de um fluxo eficiente, eliminando gargalos e impedimentos para entregar valor mais rápido ao cliente. Isso envolve estudar a ciência das equipes multidisciplinares; temos parceria com a Universidade do Norte do Texas para estudar este tema. Lá, são conduzidos muitos experimentos para definir a repetição de padrões em muitos contextos, o que possibilita a agilidade por toda a empresa. Atualmente estamos trabalhando em alguns projetos acadêmicos que serão publicados nos próximos meses e no compartilhamento deste aprendizado com o mundo Ágil.

Um exemplo de Sistema de Equipe Multidisciplinar é o Scrum de Scrums e o Meta Scrum. Nós os definimos como padrões comportamentais e por meio da observação podemos identificar o que funciona e o que atrapalha. Assim podemos experimentar e ajustar o processo para observar o efeito sobre o comportamento. Quando refinamos as interações entre o time, iteramos e documentamos isso como padrão tanto positivo quanto negativo.

Outro exemplo é a ideia de criar "Scrum Masters de Scrums" e fazê-los responsáveis pelo lançamento do trabalho do time em conjunto. Percebemos que isso cria um estilo de liderança com comando e controle, e neste momento sabemos que temos uma única pessoa "dizendo" o que as equipes devem entregar. Isso diminui a colaboração entre os times pois agora estão sendo medidas e responsabilizadas por um gerente.

Reconhecemos que simplesmente manter um grupo de pessoas utilizando Scrum não irá criar a equipe perfeita e quando nos envolvemos em múltiplos times percebemos que os desafios aumentam. Mudar o comportamento e ensinar habilidades de trabalho em grupo é essencial.

O Cynefin nos possibilita entender a complexidade dos sistemas adaptativos, assim como as equipes que são definitivamente complexas e têm comportamento imprevisível. É importante entender que é a interdependência de tarefas que determina se é preciso um time e não uma pessoa na estrutura de reportar, independente do que diz o organograma. Se um indivíduo precisa trabalhar consistentemente com outro indivíduo para entregar algo, então os consideramos interdependentes e formamos um time, independentemente das linhas de reporte. Essas pessoas trabalham interdependentemente, adaptativamente e dinamicamente em direção aos objetivos e valores compartilhados.

Estudando o trabalho de David Snowden com professores na UNT, começamos a definir modeladores de comportamento no qual os times podem se auto identificar, para então se auto corrigir, junto com mentoria e suporte adjunta dos time de Scrum Master.

Estamos definindo o significado de agilidade para a Toyota como empresa global. Pegamos o conhecimento de muitas indústrias e estamos devolvendo para a comunidade quando tentamos encontrar a sinergia entre o Sistema Toyota de Produção/Lean e o mundo Ágil. Por exemplo, recentemente lançamos um treinamento aberto chamado 'O jeito Toyota para Scrum', e depois do sucesso dos testes iniciais estamos planejando uma disponibilidade mais abrangente deste treinamento. Continuamos aprendendo coisas novas e evoluindo à medida que nosso entendimento sobre este mundo se aprofunda.

InfoQ: O que vocês aprenderam?

Thurlow: Aprendemos que agilidade é difícil, realmente difícil. Também não existe algo como a transformação Ágil. Fundamentalmente, deve-se mudar seu modelo de operação e empreender uma transformação organizacional para alcançar a agilidade que deseja. O Scrum é apenas mais um item na caixa de ferramentas para ajudá-lo a fazer isso. Também é preciso de senso de urgência. Se o board executivo (C level)não enxergar uma razão convincente para mudar, haverá chances de deixar as coisas piores desordenando a condição atual, tornando a resistência à mudança mais esmagadora e sem nenhuma ordem para atingir aquela mudança.

Também percebi que nem todos precisam ser ágeis! Se estiver entregando placas de concreto, provavelmente não precisa fazer isso em uma sprint de duas semanas, porque este cenário não exige mudanças rápidas. Claro que o Scrum irá fornecer uma plano de cadência, mas o Scrum foi projetado para trabalhar em demandas complexas com sistemas complexos. Essas são áreas onde uma abordagem linear e pensamento fixo não são efetivos.

Em um trabalho de demanda fixa e pouca variação, talvez a agilidade não seja tão importante quanto ser Lean. Otimizar a eficiência do fluxo de produto pode ser muito mais benéfico. Entretanto, se trabalhar em um mercado que envolve mudanças rápidas, a agilidade é crucial. Lembrando que, podemos ser Lean e não ser Ágil, ou então, podemos ser Ágil e não ser Lean. Sugeriria que o Ágil com o Lean é uma combinação vitoriosa. Poderíamos dizer que a agilidade entrega a coisa certa e o Lean entrega certo a coisa.

InfoQ: Quão bem sucedido é o Scrum para você?

Thurlow: Com um time ou um produto de startup, o Scrum é mais simples de se aplicar e muito efetivo. Se houver um grupo com indivíduos altamente talentosos trabalhando na mesma sala, com desafios e motivações, irão criar coisas fantásticas. O Scrum é altamente efetivo em encurtar o ciclo PDCA e entregar resultados rápidos, possibilitando resposta rápida para a mudança, a chave para os princípios ágeis.

Ao escalar o Scrum em um time com muitos produtos, o backlog do produto se transforma em um backlog do time. Neste momento, a priorização passa a ser mais desafiadora com mais stakeholders disputando o primeiro lugar. Manter o backlog do time visível para a liderança é essencial para possibilitar discussões em tempo real e priorizações. Quando digo visível, me refiro a um quadro físico em uma grande parede com diversos quadros brancos pregados juntos. Isso é exatamente o que estamos fazendo no Toyota Connected.

Escale isso para muitas equipes no mesmo produto e certamente alguns padrões se tornarão úteis; padrões que possibilitam um backlog e gerenciamento de produto com alto nível. Foi neste ponto que começamos a utilizar o Meta Scrum para o gerenciamento de backlog, assim como o Scrum de Scrums para gerenciar as entregas entre equipes múltiplas e interdependentes. A coordenação de múltiplas dependências entre os times e produtos é amplificada, logo as necessidades de encontrar técnicas pragmáticas para coordenar a colaboração são essenciais.

Quando escalamos muitas equipes com diversos produtos, a complexidade escala exponencialmente. Ao lançar numerosas dependências, com restrições, se são vários parceiros ou fornecedores, ou construídos com as restrições de uma empresa global, a agilidade se torna muito mais complexa para ser alcançada. Os conceitos são os mesmos, as ferramentas são as mesmas, mas o contexto altera tudo. Aqui é onde o desenho organizacional e o modelo de operação precisa mudar e evoluir.

Claramente, reconhecemos que não existe um framework escalável que se encaixe em todas as situações. Os frameworks são contextos agnósticos, mas o contexto de escala é tudo. Padrões, técnicas, experimentos e empoderamento do trabalho em equipe são essenciais, contudo, não existe bala de prata - pelo menos não ainda.

InfoQ: Quão crucial é o papel do Product Owner?

Thurlow: O papel do Product Owner (PO) é crucial para o sucesso da equipe Scrum e também o mais desafiador de fazer direito. A noção do guia Scrum sobre o trabalho pesado feito pelo time para criar o backlog não funciona na prática quando escalamos. Desenvolvedores nem sempre possuem as habilidades necessárias ou desejam ser os donos do backlog do produto, mesmo que o PO ainda seja o responsável. Ser ágil para vender, comercializar um produto e fazer a análise de negócios requeridas neste papel exige certas disciplinas que não são comuns em engenheiros técnicos, além disso, não é a melhor utilização de suas habilidades e talentos. Se este papel não existe ou se envolve com o time, então o time passa a ser o PO de qualquer maneira. Claro que isso depende da forma como a propriedade do produto (PO Ownership) é definida, assim como a visão geral de gerenciamento de produto.

Diversas abordagens de escalonamento tentam corrigir isso através de diversos meios, mas percebemos que precisamos de um verdadeiro PO neste papel, e embora seja de um responsável singular, o papel da propriedade do produto é uma atividade que envolve muitas pessoas. O conceito de time único não escala sem adaptação e imensa disciplina, assim como tal disciplina é difícil de ser alcançada em empresas grandes.

Através de estudos do papel de PO, entendemos que precisamos codificar o trabalho atual da criação de backlog. Em seguida, precisamos do backlog para o time trabalhar nele e refinar. Portanto, criamos uma atividade chamada Desenvolvimento de Backlog do Produto.

O Desenvolvimento do Backlog do Produto é o ato de criar Itens de Backlog do Produto. Esse é um processo corrente no qual o PO, junto com qualquer stakeholder requerido, criam itens de Backlog. Os stakeholders requeridos podem incluir clientes, especialistas em algum assunto, usuários do sistema, representantes do negócio ou qualquer suporte vindo de qualquer grupo necessário para ajudar o PO a desenvolver itens de backlog. Durante o Desenvolvimento do Backlog de Produtos, são criados a visão do produto, estratégia e roadmap, além de inspecionados e revisados. O Desenvolvimento do Backlog de Produtos acontece em cada sprint.

Pode parecer simples e provavelmente outros diriam que não é necessário, já que o guia do Scrum define isso de forma genérica e pouco explícita, mas descobrimos que não o define bem o suficiente, então simplesmente fizemos como expliquei.

Claro que promovemos e possibilitamos uma comunicação aberta e efetiva entre os times e os atuais clientes, mas normalmente descobrimos que ser um PO ativamente engajado é mais eficiente no dia-a-dia, especialmente onde temos fusos horários diferentes, idiomas e limitações tecnológicas. Também usamos o conceito de Chief Product Owner (CPO) quando temos muitas equipes trabalhando no mesmo produto. O CPO permite a comunicação eficaz entre muitas equipes e um cliente, além de trabalhar com outros POs para garantir que todos estejam alinhados e concentrados nas prioridades mais altas.

InfoQ: Como o board executivo (C-level) se comporta no mundo Ágil?

Thurlow: O engajamento das lideranças executiva e sênior é a chave, uma vez que comece a escalar o número de produtos ou de equipes. No Toyota Connected, escalamos o papel do PO para o nível executivo e conduzimos um Meta Scrum Executivo mensal para rever o progresso da empresa, garantir o alinhamento da visão e da estratégia, e tomar decisões críticas de priorização.

Também temos uma Equipe de Ação Executiva (em inglês, EAT), onde os mesmos executivos-sênior se reúnem frequentemente para rever os impedimentos (tarefas bloqueadas) e atribuí-los a si mesmos para a resolução. Isso significa que a EAT se comporta como uma equipe Scrum, puxando os impedimentos do backlog e executando o trabalho para resolvê-los. Em uma entrega de produtos multi-fornecedor ou multi-afiliado maior e mais complexa, também podemos ter uma Equipe de ação da Liderança (em inglês, LAT) para resolver os impedimentos ou tomar decisões rápidas antes que seja escalado para o EAT.

Se não houver este engajamento, perceberá que a habilidade para mudança de direção ou prioridade rápida diminui e, com isso, a agilidade e, possivelmente, a competitividade.

O engajamento executivo também é necessário para atacar os silos que existem em grandes empresas e corporações. É um desafio eliminar os silos que envolvem e protegem sua existência.

Isso torna o fluxo de valor do design longo e doloroso, e como Peter Drucker certa vez disse: "qualquer inovação em uma corporação estimulará o sistema imunológico corporativo a criar anticorpos que irão destruí-la". Para realmente transformar uma organização, devemos otimizar o sistema para o fluxo de valor, e isso significa olhar para todo o sistema e mudá-lo, se isso for o necessário.

Devemos parar de fazer o Ágil e começar a ativar o fluxo e encurtar os ciclos de feedback. Então nos tornaremos ágeis.

InfoQ: A Toyota é conhecida pelo Sistema Toyota de Produção e pela Produção Lean. Como o Ágil e o Scrum se relacionam com isso?

Thurlow: O Scrum, o framework Ágil predominante, foi baseado no Sistema Toyota de Produção (muitos se referem como Lean, um termo empregado pelos autores do livro: A máquina que mudou o mundo, e a primeira maior publicação sobre como a Toyota manufatura seus produtos), e como Ken Schwaber me disse recentemente, sobre a influência da DuPont para adotar um plano de abordagem empírica. De fato, o Scrum é simplesmente um plano de abordagem empírico com ciclos rápidos de feedback construído para possibilitar certas características de comportamento em um time. Isso é o PCDA codificado com etapas balizadas pelo tempo.

Quanto tempo deveríamos planejar, fazer, checar e finalmente agir? E o que realmente acontece em cada uma dessas fases? O Scrum codifica isso fornecendo disciplina em volta do PDCA.

O Sistema Toyota de Produção/Lean é o padrão de ouro para o desenvolvimento de produtos Lean. Codificar o PDCA utilizando o Scrum é fornecer mecanismos através dos quais podemos melhorar nossa capacidade de respostas para mudança, e inspecionar constantemente e adaptar o valor que estamos entregando para nossos clientes.

Entretanto, o Ágil não economiza o Lean e o Lean não economiza o Ágil; o movimento Ágil está possibilitando empresas que já são Lean ou muitas que desejam ser Lean para tomar decisões rápidas. Estamos utilizando frameworks como o Scrum e ferramentas do Sistema Toyota de Produção para possibilitar a agilidade nos negócios, e assim desenvolver a habilidade para responder mais rapidamente às tendências do mercado. "Agilidade não é o objetivo, é um resultado ou uma consequência."

InfoQ: Se os leitores do InfoQ quiserem aprender mais sobre "O Jeito Toyota para Scrum", onde poderão encontrar algo?

Thurlow: Neste momento estamos testando alguns treinamentos abertos. Temos apenas duas aulas beta e iremos ter mais duas, uma em Portland e outra em Dallas. Também patrocinamos o Agile Camp. O evento em Dallas está em preparação final e será anunciado em breve em diversas mídias sociais pelo Agile Camp.

Também oferecemos um desconto de 100% para nossos militares veteranos e servidores da lei ([ambos norte-americanos] para que possam participar e aprender novas habilidades para reingressar no mercado de trabalho e ajudá-los a servir o público de forma mais efetiva.

Sobre o entrevistado

Nigel Thurlow é teórico organizacional, líder em melhoria contínua, especialista Ágil e Scrum, e C-Agile no Toyota Connected. Internacionalmente reconhecido na indústria como especialista nas abordagens Lean e Ágil, está alavancando o poder do Sistema Toyota de Produção e "O Jeito Toyota" para melhorar e desenvolver agilidade no desenvolvimento de produtos Lean.