À medida que mais pessoas se interessam pelas ideias Lean e sua aplicação ao trabalho do conhecimento e gerenciamento de projetos, é útil encontrar maneiras que tornem mais fácil começar ou aprender alguns conceitos básicos que podem levar a percepções mais profundas posteriormente. Para aqueles que estão curiosos sobre o kanban em um contexto de escritório, não é incomum encontrar pessoas que estão usando Scrum atualmente ou que têm algum entendimento do Scrum como representante do pensamento ágil. De uma forma ou de outra, os usuários Scrum são um importante constituinte do público Kanban. Visto que o Scrum pode ser descrito como uma declaração na linguagem que usamos para descrever os sistemas kanban, também é bastante fácil elaborar esse caso para descrever os híbridos Scrum / Kanban. Isso pode ser útil para times Scrum existentes que procuram melhorar sua escala ou capacidade.1 .

A ideia de usar um quadro de tarefas simples com fichas ou post-its é tão antiga quanto o próprio Agile. Uma variação simples disso é um quadro de tarefas com um fluxo de trabalho simples Pendente -> Em processamento -> Completo . Os cartões representam itens de trabalho que estão no escopo de trabalho atual. Os nomes podem ser associados aos cartões para indicar quem está trabalhando em quê. As equipes ágeis vêm usando esse tipo de método há muito tempo, e algumas pessoas apontaram no início que isso tinha alguma semelhança com a noção de kanban em sistemas enxutos.

Claro, existe uma variedade de ferramentas eletrônicas que executam essas funções, mas o quadro de tarefas simples representa alguns princípios enxutos que considero tecnologia simples e controle visual muito valiosos . A utilidade de um método tão simples de gerenciamento de fluxo de trabalho é que ele é fácil de gerenciar e, mais importante, é fácil de mudar . Estar amontoado em torno de um monitor de computador, mesmo um muito grande, não é de forma alguma um substituto para a interatividade tátil e social que acompanha a manipulação de um grande quadro de tarefas. Talvez um dia isso aconteça. Hoje nao. As ferramentas eletrônicas são boas para gerenciar listas de coisas, como backlogs e bugs, e para produzir relatórios. Ferramentas simples podem ser um conceito difícil de explicar aos fanáticos por tecnologia, mas também podemvalor .

Um problema com o quadro de tarefas de cartão de índice básico é que não há nada que o impeça de acumular uma grande pilha de trabalho em andamento. O time-boxing, por sua natureza, define um limite de quanto WIP pode ser, mas ainda pode permitir muito mais do que seria desejável.

Se um kanban é um token que representa uma solicitação de trabalho e nosso quadro de tarefas ainda pode ficar fora de controle, então qual é o problema aqui? O problema é que um kanban é mais do que apenas uma solicitação de trabalho em um cartão, e colocar notas adesivas em um quadro branco não é suficiente para implementar um sistema pull.

Um kanban é mais do que um cartão de índice

Em uma economia moderna, a produção e distribuição de bens e serviços escassos são regulados por um sistema de dinheiro e preços. O dinheiro pode ser representado por notas monetárias, que têm pouco valor intrínseco, mas que, por acordo, podem ser trocadas por bens e serviços reais. A existência de um meio de troca neutro torna possível um sistema de cálculo econômico da escassez relativa da oferta de bens em uma economia. Esse sistema de preços é um mercado. Os mercados comunicam o valor da produção e distribuição econômica aos seus participantes.

Se uma nota monetária pode ser trocada por um objeto de valor real, então deve haver alguma maneira de impor a escassez das notas de uma forma que corresponda à escassez de valor real na economia. Na prática, algum tipo de instituição deve fazer cumprir essa escassez. A saúde de uma economia de mercado depende muito da capacidade de sua instituição monetária de coordenar a oferta de moeda com a oferta de bens e serviços. Em uma economia doentia, os preços instáveis dificultam o cálculo econômico e atrapalham a comunicação entre produtores e consumidores, necessária para uma produção e distribuição eficientes.

Um kanban representa uma parte da capacidade produtiva de alguma economia interna fechada. É um meio de troca de bens e serviços fornecidos pelas operações de um sistema de recursos produtivos. O fornecimento de kanban em circulação é controlado por alguma função reguladora que reforça seu valor. Ou seja, um kanban é uma espécie de moeda privada e o gerente do chão de fábrica é o banco que o emite, para fins de cálculo econômico.

Se você levar mais longe a analogia da moeda, poderá dizer que o Kanban não tem nada a ver com as cartas. Assim como dinheiro não tem a ver com contas. Kanban trata dos limites, da quantidade em circulação. A maneira como isso é representado em uma transação é quase sempre acidental.

Uma regra simples para entender tudo isso pode ser:

Um cartão de tarefa sem limite não é um kanban da mesma forma que uma fotocópia de uma nota de um dólar não é dinheiro.

Se você usar um token durável como um cartão de plástico, isso é fácil de gerenciar: controle o número de cartões em circulação. Se todos os cartões disponíveis já estão em circulação, então a próxima pessoa que vier procurar um terá que esperar até que um retorne. Esse é o objetivo do sistema kanban. No entanto, se você usar um meio mais descartável, como cartões de índice ou notas adesivas, precisará de outro mecanismo para regular o "suprimento de dinheiro". Em nosso caso, simplesmente escrevemos a quantidade de kanban em circulação no quadro de tarefas e alocamos novos cartões de acordo com esse limite.

Isso significa que um kanban tem duas funções: é uma solicitação para fazer algo em particular, mas também é permissão para fazer algo em geral. Essa segunda noção de permissão é onde as pessoas que são novas no pensamento enxuto tendem a ter dificuldades. Mas é precisamente assim que podemos "otimizar o todo" ou "subordinar à restrição".

Crocante por fora, mastigável por dentro

Assim como um cartão de índice não regulamentado em um quadro de cortiça não é um kanban, o planejamento de iteração time-boxed não é puxado. Nenhuma interpretação razoável do Lean envolve construir uma previsão de um mês, a menos que o tempo de ciclo de cada ordem de serviço também seja um mês. Um mês de material em processo é certamente um tamanho de lote muito menor do que 3 meses ou 18 meses, mas se a lista de pendências de iteração contiver 20 itens de trabalho, isso ainda significa cerca de 19 a mais do que precisa para ser um sistema pull.

No entanto, não é difícil aumentar o Scrum com algumas práticas simples que nos movem em direção a um fluxo de trabalho mais reconhecidamente enxuto. O mais óbvio é a redução do comprimento da iteração, embora isso não seja isento de problemas 2 . Como veremos, é possível aprimorar incrementalmente o Scrum com mais e mais recursos do tipo pull até que tudo o que resta do processo original seja uma estrutura vestigial. A abordagem simples é começar com iterações semelhantes ao Scrum e processo de planejamento de iteração e começar a adicionar recursos de pull ao processo interno da equipe.

Uma técnica simples que nos aproxima muito de nossa definição de kanban é definir um limite de multitarefa para indivíduos. Você pode ter um princípio simples como: prefira concluir o trabalho a começar um novo, ou pode expressar isso como uma regra que diz: tente trabalhar em apenas um item por vez, mas se você estiver bloqueado, poderá trabalhar em um segundo item, mas não mais . Em nosso exemplo, essa regra nos dá um limite WIP efetivo de 6.

Outra técnica comum é a vinculação tardia de tarefas aos proprietários. Algumas equipes atribuirão previamente todas as tarefas conhecidas durante o planejamento da iteração. Geralmente não é uma boa ideia porque cria artificialmente um caminho crítico. Esperar até o “último momento de responsabilidade” para atribuir tarefas às pessoas maximiza o conhecimento e aproxima você de puxar.

Só porque qualquer pessoa pode ter mais de um item em processo, não significa que todos devam ter mais de um item em processo. Um problema com nossa regra de multitarefa é que ela otimiza localmente sem considerar o todo. Um limite de WIP total implícito de 6 ainda é mais WIP do que provavelmente deveríamos tolerar para nossos três trabalhadores. Um limite de 4 de 5 itens totais em processo ao mesmo tempo ainda permite algumas exceções multitarefa, mas não permite o comportamento obviamente disfuncional de todos que carregam dois itens. Nesta etapa, ultrapassamos uma regra sobre os indivíduos e criamos uma regra sobre os próprios cartões de tarefas. Ou seja, transformamos nossos cartões em kanban.

Outro aprimoramento que podemos fazer em nosso quadro anterior é adicionar uma fila pronta entre o backlog e o trabalho em andamento. A fila pronta contém itens pendentes do backlog, mas têm alta prioridade. Ainda não vinculamos nenhum indivíduo a essas tarefas, mas assim que alguém se tornar disponível, deve realizar uma dessas tarefas em vez de escolher algo do acúmulo geral. Isso nos permite separar o processo de atribuição de trabalho do processo de priorização de trabalho e simplifica a atribuição. A fila pronta também tem um limite de kanban, e deve ser um limite pequeno, já que seu único propósito é indicar qual item de trabalho deve ser iniciado a seguir.

Agora podemos começar a ver alguns dos mecanismos de tração e fluxo:

1. David conclui uma tarefa e a move para a coluna “concluída”.
2. David puxa um novo kanban da fila de espera e começa a trabalhar.
3. A equipe responde ao evento pull e seleciona o próximo item de prioridade para entrar na fila de espera.

Neste ponto, agora estamos operando um sistema pull kanban simples. Ainda temos nosso ciclo de iteração e planejamento com limite de tempo, então talvez possamos chamar isso de sistema Scrumban!

Agora que temos um senso de capacidade e atração, é natural pensar sobre o fluxo. Dividir nosso nebuloso estado “em processo” em estados mais bem definidos pode dar a todos mais visibilidade sobre os pontos fortes, fracos e a saúde geral da equipe. Até mesmo fluxos de trabalho ágeis como o Extreme Programming têm funções e estados relativamente bem definidos, e um fluxo de trabalho suave entre esses estados é tão importante quanto um fluxo de trabalho regular em todo o processo.

Aqui, dividimos o processo em dois estados: especificar e executar . Especificar refere-se à definição de quaisquer critérios necessários para determinar quando o item de trabalho pode ser considerado concluído. Execute é fazer o trabalho necessário para trazer esse item de trabalho a um estado que satisfaça esses critérios. Dividimos nosso limite de WIP anterior de 5 entre esses dois estados. Especificar é considerado levar menos tempo neste caso, portanto, é dado um limite de 2. Executar consome o limite restante de 3. Podemos alterar essa proporção com o passar do tempo e nosso desempenho mudar.

Como agora estamos pensando mais sobre o fluxo, os detalhes adicionais do fluxo de trabalho sugerem fortemente o uso de um diagrama de fluxo cumulativo para rastrear o trabalho e medir nosso desempenho. Um simples burndown informa se você está agregando valor ou não, mas não muito sobre o motivo. O CFD comunica muitas informações adicionais sobre prazos de entrega e estoques que podem diagnosticar problemas ou mesmo evitá-los.

Definindo nosso fluxo de trabalho um pouco melhor, também podemos levar em conta alguma especialização funcional. Nesse caso, pode ser uma especialização leve, em que alguns de nós preferem fazer um tipo de trabalho mais do que outro, embora sejamos capazes de fazer tudo. É importante entender que esse tipo de sistema de fluxo de trabalho pull permite a especialização, mas não impõe a especialização. A equipe é responsável pelo trabalho e pelo fluxo de trabalho, e cabe à equipe descobrir como fazer isso com eficiência.

Se deixarmos que a pessoa que melhor desempenha a função “especificar” cuide mais desse trabalho, talvez também seja necessário coordenar as transferências entre nós. Adicionar a coluna especificar-completo comunica à equipe que um item de trabalho que estava anteriormente no estado especificado agora está pronto para ser puxado por qualquer pessoa que deseja movê-lo para o estado de execução. O trabalho que ainda está no estado especificado não é elegível para puxar ainda. Se o proprietário de um tíquete no estado especificado deseja entregá-lo, ele pode colocá-lo no buffer completo. Se ele não quiser transferi-lo, ele pode movê-lo diretamente para o estado de execução, desde que haja capacidade disponível. Pode ser que o estado de execução esteja cheio e o único trabalho elegível seja puxar outro tíquete da fila pronta para especificar.

Como adicionamos uma nova coluna para nosso buffer de transferência, também estamos aumentando o limite de WIP em um pequeno valor. A desvantagem é que o aumento no lead time devido ao novo estoque deve ser compensado pela diminuição no lead time devido à vantagem da especialização. Também mitigamos o impacto desse novo inventário agrupando o limite de WIP no estado anterior. Isso tem a consequência muito benéfica de tornar o buffer de especificação completa um acelerador variável para a estação anterior. Quanto mais trabalho se acumula no buffer de especificação completa, menos trabalho pode estar em andamento no estado de especificação, até que a especificação seja totalmente encerrada. Mas nós vemos isso chegando, não "simplesmente acontece".

Se vamos permitir a especialização do fluxo de trabalho e as transferências resultantes, também precisaremos de algum acordo sobre quais resultados esperar em cada transferência. Podemos fazer isso definindo alguns padrões de trabalho simples ou procedimentos padrão para cada estado. Eles não precisam ser complicados ou exaustivos. Aqui, eles são marcadores ou listas de verificação simples desenhados diretamente no quadro de tarefas. Eles só precisam ser suficientes para evitar mal-entendidos entre produtores e consumidores. Esses padrões são feitos e pertencentes à equipe, e eles podem alterá-los conforme necessário, de acordo com a prática do kaizen . Colocá-los em um meio flexível, como um quadro branco ou wiki, reforça a noção de propriedade da equipe.

Scrumban nível 2

Na versão básica do Scrumban descrita até agora, a revisão da iteração e o ciclo de planejamento acontecem exatamente como no Scrum comum. Mas, à medida que nosso processo de produção amadureceu, também oferecemos a nós mesmos algumas ferramentas para tornar o processo de planejamento mais eficiente, mais ágil e mais integrado ao negócio que atende.

Com o sistema puxado instalado, nosso fluxo se tornará mais suave à medida que nossa capacidade de processo melhorar. Podemos usar nossos buffers entre processos e diagramas de fluxo para nos mostrar nossas fraquezas de processo e oportunidades para kaizen. À medida que nos aproximamos do nível de produção, começaremos a nos preocupar menos com o burndown e mais com o tempo de ciclo, pois um é o efeito e o outro é a causa. O lead time médio e o tempo de ciclo se tornarão o foco principal do desempenho. Se o tempo de ciclo estiver sob controle e a capacidade da equipe for balanceada em relação à demanda, o tempo de execução também estará sob controle. Se o tempo de ciclo estiver sob controle, os burndowns são previsíveis e desinteressantes. Se burndowns são desinteressantes, então o estabelecimento de metas e os esforços heróicos arriscados são desnecessários. Se burndowns são desinteressantes, então, os acúmulos de iteração são apenas inventário com o propósito de planejar a regularidade e alimentar o sistema pull. Como tal, eles devem ser os menores estoques possíveis que otimizam o custo de planejamento.

Como a equipe agora puxa o trabalho para uma pequena fila pronta antes de puxá-lo para o WIP, da perspectiva da equipe, a utilidade do backlog de iteração é que sempre contém algo que vale a pena fazer em seguida. Portanto, devemos usar o mecanismo de menor desperdício que satisfaça essa condição simples.

Um mecanismo simples que se ajusta ao projeto é um limite de tamanho para a lista de pendências de iteração. Em vez de se dar ao trabalho de estimar um escopo de trabalho para cada iteração, apenas torne o backlog de um tamanho fixo que ocasionalmente chegará a zero antes que o intervalo de planejamento termine. Esse é um cálculo simples. É apenas o número médio de coisas liberadas por iteração, que por sua vez é apenas um múltiplo do tempo de ciclo médio. Então, se você tem 5 coisas em processo, em média, e leva 5 dias para completar algo, em média, você vai terminar 1 coisa por dia, em média. Se o intervalo de iteração for de duas semanas de trabalho, ou 10 dias de trabalho, a lista de pendências de iteração deve ser 10. Você pode adicionar um ou dois para preenchimento se estiver preocupado com o esgotamento. Este pode ser um ponto que se perdeu na comunidade Scrum: nunca é necessário estimar os tamanhos particulares das coisas na lista de pendências. É necessário apenas estimar o tamanho médio das coisas na carteira. A maior parte do esforço gasto estimando no Scrum é desperdício.

Em nossa encarnação final do Scrumban, o planejamento da iteração ainda acontece em um intervalo regular, sincronizado com a revisão e a retrospectiva, mas o objetivo do planejamento é preencher os slots disponíveis, não preencher todos os slots e certamente não determinar o número de slots. Isso reduz muito a sobrecarga e a cerimônia do planejamento da iteração. O tempo gasto no processamento em lote para estimativa de planejamento de iteração pode ser substituído por uma inspeção de controle de qualidade no momento em que o trabalho é promovido para a fila de espera. Se um item de trabalho estiver malformado, ele será devolvido e os infratores reincidentes obterão uma análise de causa raiz.

Fora com as rodinhas de treinamento

Se você chegou até aqui em sua evolução, provavelmente perceberá que os mecanismos originais do Scrum não estão mais fazendo muito por você. Scrum pode ser um suporte útil para manter uma equipe unida enquanto você cria uma solução mais otimizada no local. Em algum ponto, você pode se desprender do casulo e permitir que o sistema de tração abra suas asas e voe.

O primeiro passo além do Scrum é separar os períodos de planejamento e liberação. Pode haver um intervalo conveniente para agrupar recursos para liberar e pode haver um intervalo conveniente para reunir as pessoas para planejar. Se tivermos um método de planejamento mais enxuto e mais direcionado ao pull, não há realmente nenhuma razão para que esses dois intervalos sejam iguais. Sua equipe de operações pode querer lançar uma versão uma vez por mês, e seus gerentes de produto podem querer estabelecer uma rotina de priorização semanal. Não há razão para não acomodá-los.

Depois de quebrar a caixa de tempo, você pode começar a ficar mais enxuto sobre a construção do backlog. Agilidade implica capacidade de responder à demanda. O backlog deve refletir o entendimento atual das circunstâncias de negócios com a maior freqüência possível. O que quer dizer que o backlog deve ser orientado por eventos. O planejamento do backlog com prazo definido é apenas isso, onde o evento é um cronômetro, mas, uma vez que o vemos dessa forma, podemos imaginar outros tipos de eventos que nos permitem responder mais rapidamente às prioridades emergentes. Como nosso sistema já demonstra tração e fluxo, essa capacidade de resposta aumentada não deve ter nenhum custo para nossa eficiência atual.

O problema que estamos tentando resolver é:

O processo de planejamento de trabalho ideal deve sempre fornecer à equipe de desenvolvimento a melhor coisa para trabalhar a seguir, nem mais nem menos.

Um planejamento adicional além disso não agrega valor e, portanto, é um desperdício. O planejamento cronometrado no estilo Scrum geralmente fornece um backlog muito maior do que o estritamente necessário para selecionar o próximo item de trabalho e, como tal, é um inventário desnecessário e, portanto, desperdício desnecessário.

O próximo evento que podemos considerar para programar atividades de planejamento é o conceito de um ponto de pedido . Um ponto de pedido é um nível de estoque que aciona um processo de pedido de novos materiais. À medida que puxamos os itens do backlog para o processo, o backlog diminuirá até que o número de itens restantes caia abaixo do ponto de pedido. Quando isso acontece, um aviso é enviado aos responsáveis para organizar a próxima reunião de planejamento. Se nosso backlog atual é 10, nosso rendimento é 1 / dia e definimos um ponto de pedido em 5, então esse planejamento acontecerá cerca de uma vez por semana.

Uma vez por semana pode ser razoável se as pessoas forem difíceis de programar ou precisarem de algum tempo para priorizar. No entanto, se eles estiverem mais disponíveis do que isso, podemos definir o ponto de pedido mais baixo. Se os planejadores puderem responder em um dia, então talvez possamos definir o ponto de pedido em 2. Se o ponto de pedido for 2, então pode não haver necessidade de manter uma carteira de pedidos de 10. Talvez possamos reduzir a carteira para 4 ... e reduza nosso prazo de entrega em 6 dias no processo.

O estado final dessa evolução é puxar, ou priorização sob demanda. Se os planejadores puderem tomar uma boa decisão com rapidez suficiente e não houver economia de escala em agrupar as decisões de prioridade em lote, o tamanho do backlog só precisa ser 1. No momento em que o item é puxado pela equipe de desenvolvimento, o planejamento a equipe é sinalizada para começar a selecionar o próximo item. Se a equipe de planejamento for rápida o suficiente em sua resposta, a equipe de desenvolvimento nunca parará. Se houver alguma variação ou atraso na resposta, um acúmulo de 2 pode ser necessário para evitar paralisações. Mas 2 ainda é muito menor e mais magro do que 10. Ou 20. Ou 50, que é algo que vi com mais frequência do que gostaria.

O mesmo tipo de lógica pode ser aplicado ao intervalo de liberação. Existe um tamanho de lote ideal para lançamentos e devemos primeiro tentar encontrá-lo e, em seguida, tentar melhorá-lo. O resultado de nossos esforços será, em última análise, recursos sob demanda.

Mesmo nesse nível, ainda temos um sistema kanban bastante básico. A partir daqui, podemos adicionar decomposição de item de trabalho (raias) ou fluxo de dependência estrutural para escala adicional. Junto com uma divisão de trabalho iluminada , é assim que acreditamos que o Lean mostra o caminho para dimensionar o Agile até a empresa.

1. apesar do fato de que a ideia do kanban é pelo menos 40 anos mais velha
2. sobre a qual provavelmente irei escrever em outro post algum dia

Next up

Previous

Scrum Ban

Description