Kanban [com K maiúsculo], foi criado por Taiichi Ohno (Toyota),
é um sistema de controle da cadeia logística de produção e do estoque de insumos que este sistema necessita.
O Kanban (JIT – Toyota) não é exatamente o Kanban (LeanKanban – David Anderson).
Kanban para desenvolvimento de software foi um conceito trazido por David Anderson, com contribuições de Corey Ladas (Scrumban) adaptado para o ecossistema de TI.
Quando falamos de Kanban em desenvolvimento de software, existem 3 elementos básicos:
- Limitar o trabalho em andamento.
- Melhoria do fluxo e identificação de gargalos.
- Gestão visual do fluxo e do trabalho em andamento.
Kanban tem como objetivo, melhorar a comunicação e transparência sobre o fluxo de trabalho.
Kanban não é um método ágil, e nem precisa do manifesto ágil.
É um método pouco intrusivo e de fácil adoção.
Se tua equipe não é bem organizada, isso não impede de aplicar Kanban.
O Kanban é adaptável ao teu cenário, e a partir dali, você vai começar a moldar teus processos,
com os direcionamentos oferecidos pelas práticas do Kanban.
É possível aplicar Kanban com cascata, com Scrum.
Kanban não fica martelando o que se deve fazer, é uma abordagem de gestão de mudança.
Kanban é uma mudança de visão, parar de pensar em esforço no trabalho, e começar a pensar em filas.
Kanban é reativo, não tem dogmas, não é como metodologias ágeis que impõe regras, receitas.
A ferramenta de mudança é você.
Uma crítica comum é dizer que a empresa colocou um quadro Kanban, começou a colocar os post-its,
e então adotou o Kanban, sim, isso é uma maneira de começar com o Kanban, só não pode parar por aí.
Kanban não se resume a gestão visual.
O perigo é colocar o quadro Kanban no projeto, para visualisar o trabalho, conseguir ver que realmente melhorou a visibilidade, mas esquecer das métricas, e das práticas que realmente fazem o Kanban tranformar para melhor o processo da empresa.
Por meio de sua natureza visual, o Kanban melhora a comunicação e colaboração entre os os indivíduos.
Da visibilidade a quais demandas estão sendo executadas a todo momento, quais itens são mais importantes, o que está bloqueando o progresso.
As práticas Kanban ajudam na organização e priorização do trabalho a ser feito.
Princípio de Pareto: A maior parte do resultado é determinada por uma pequena parcela de fatores.
Priorizando as tarefas de maior impacto/importância ao usuário final.
Um dos objetivos centrais é visualizar os gargalos e problemas no fluxo, tornando-os evidenciados.
Por exemplo, as tarefas que se acumulam em uma coluna indicam um gargalo e isso fará com que a equipe se concentre nessa etapa para eliminar o problema.
A produtividade não é medida pela quantidade de tarefas que estão trabalhando ao mesmo tempo (WIP)
A produtividade é medida na entrega de valor ao cliente.
Kanban foca em aumentar a capacidade na entrega final e equilibrar a quantidade de tarefas em andamento.
Uma frase bem comum no meio de quem pratica Kanban é: “pare de começar e comece a terminar”.
O Quadro Kanban mais simples possível contém colunas “A fazer” e “Feito”.
A definição de colunas pode ser simples ou conter toda uma riqueza de detalhes, como etapas intermediárias, filas, aprovações, etc.
O Quadro pode conter (a fazer, fazendo, feito) ou tipo do trabalho a ser feito (desenvolvimento, análise, teste, deploy) para nomear as etapas do fluxo.
Não há uma regra estabelecida para isso no Kanban.
O sistema ou fluxo só irá puxar trabalho caso ele tenha capacidade para tal, evitando assim gerar filas de trabalho concorrentes e deixando explícitos os gargalos que existem no seu fluxo.
As quatro principais métricas de fluxo são:
- WIP: o número de itens de trabalho iniciados, mas não concluídos;
- Throughput: o número de itens de trabalho concluídos por unidade de tempo;
- Work Item Age: o tempo decorrido entre o início de um item de trabalho e o momento atual;
- Cycle Time: a quantidade de tempo decorrido entre o início do trabalho e a conclusão de um item de trabalho.
A prática de políticas explícitas significa eliminar as barreiras invisíveis de convivência e a forma de conduzir o trabalho.
A partir do momento que deixamos explícito como as coisas ocorrem ou porque ocorrem da forma que são, abrimos espaço para discussões baseadas em fatos, objetivas e racionais, deixando o desgaste emocional em segundo plano.
Asseguradamente a facilitação dessas discussões será mais fácil e menos dolorida para todos.
Métodos modernos de gestão exigem feedback rápido para funcionarem bem na velocidade com que o mercado hoje muda.
Usando Kanban você pode implementar ciclos de feedback em vários níveis, daily meetings, retrospectivas, reviews e demos com clientes.
Há uma forte relação entre a teoria das restrições, teoria das filas de Donald Reinertsen, com Kanban.
A essência que faz a agilidade funcionar vai cair sobre a teoria das filas.
E portanto, provavelmente se o Kanban tivesse tido um marketing mais forte na década de 90,
o manifesto ágil talvez não teria existido.
Um ótimo livro sobre teoria das filas é o livro A Meta de Eliyahu Goldratt
Geralmente ficamos imaginando que o trabalho não flui por quê as pessoas não tem motivação.
Às vezes a gente imagina que o trabalho não flui porque existe alguma coisa que estamos errando em estimativas.
Porque não houve um ótimo entrosamento entre as equipes, ou porque voltou mais do que devia a tarefa.
Porém, devemos entender que o trabalho do conhecimento no século 21 é extremamente propenso a ficar parado numa fila esperando alguém dar atenção.
Na área de tecnologia, um gerente de produto ou um gerente de negócio pode ter diversas ideias e em quanto essas ideias não estão sendo desenvolvidas e não estão sendo produzidas, elas entram numa fila, elas estão possivelmente num backlog, numa lista de ideias, e depois de um tempo vai cair na mão de um analista de negócio, ele vai tentar entender e logo em seguida, ele vai passar para a engenharia, ou uma área de desenvolvimento de software, essas etapas têm velocidades diferentes e vai ter um buffer entre essas áreas, hoje em dia, também terá uma fila entre o front-end e o back-end, e uma fila envolvendo a qualidade, uma fila envolvendo uma validação do cliente, e no final de tudo isso, se não tiver um DevOps muito robusto, ainda vai enfrentar uma fila aguardando ser publicado, ou seja, tudo isso se resume a uma métrica bem simples, que se chama, eficiência do fluxo, a eficiência do fluxo seria basicamente a relação entre o tempo em que o trabalho fica de fato na mão das pessoas e o tempo que o trabalho fica em fila, e é principalmente considerando o trabalho de tecnologia uma porcentagem com uma eficiência muito baixa, alguns estudos apontam que flutua entre 5% e 15%, ou seja, se você tem uma eficiência do fluxo de 15% significa que 15% do tempo de trabalho está na mão das pessoas e 85% do tempo o trabalho está numa fila esperando alguém dar atenção, e isso foi possivelmente um dos insights da teoria das restrições, que é bastante focada em encontrar as restrições, podemos traduzir restrição como gargalo, e isso também foi parte do trabalho do Taiichi Ohno na Toyota e também esse insight que o Dave Anderson teve junto com o Donald Reinertsen: "focar em gerenciar as filas no sistema".
A segunda prática do método Kanban é limitar o trabalho em progresso.
Essa prática tem como objetivo reduzir o impacto das filas no trabalho.
As filas normalmente são o que causa mais impacto no sistema.
Até empresas de serviço possuem intentário em progresso.
Tudo que você prometeu ao cliente e não entregou ainda, é inventário em progresso.
Aumentar o número de tarefas acima da capacidade ótima das equipes as sobrecarregam do mesmo modo que ter mais carros do que o ideal num bairro num determinado horário, haverá engarrafamento, trânsito pesado, os carros vão andar muito lentamente, haverá gargalos, pontos em que um carro atrapalha o outro transversalmente, os cruzamentos muitas vezes se tornam um problema, o estresse aumenta, o gasto de combustível é elevado.
Todos os carros vão demorar muito mais tempo para chegar no destino, essa analogia se encaixa muito bem no fluxo de trabalho de uma equipe sobrecarregada, os trabalhos vão demorar muito mais tempo para finalizar.
Com o trânsito organizado, é possível chegar 100 carros num destino em 100 minutos, o primeiro chegando em 30 minutos, o último em 100 minutos, um após o outro, já num trânsito caótico em que 50 carros estão nas ruas ao mesmo tempo, o primieiro só chegará em 90 minutos, e o último em 120 minutos, e depois entrando mais 50 carros, só em 130 e 150 minutos, com um gasto de gasolina e estresse muito maior, com risco muito maior de um acidente, os motoristas na pressa muitas vezes acabam acelerando mais do que deviam num trecho, apertam mais do que podiam, acabam até entrando num local que não podia, existem até os desesperados que pegam o acostamento, podemos refletir e chegar a conclusões similares num projeto.
Com um WIP num patamar próximo do ótimo, é possível visualizar os gargalos, as etapas descartáveis, pontos a melhorar, coisa que num cenário caótico de inúmeras tarefas concorrentes geralmente não é possível visualizar.
As pessoas, mesmo as mulheres não são capazes de executar 3 tarefas ao mesmo tempo com o mínimo de qualidade.
Até mesmo 2 tarefas serão demasiadamente pesadas para o cérebro gerenciar caso sejam tarefas que exijam alto grau de concentração.
Então o ótimo está entre 1 tarefa complexa ou 2 tarefas mais simples de baixa exigência cognitiva.
Não são necessariamente 2 tarefas curtas de prazo menor, mas sim, 2 tarefas que exijam pouco tempo de transição para a pessoa voltar a dar continuidade nela, tarefas mais complexas demandam muitas vezes até 40 minutos de readaptação para o profissional poder pegá-la novamente e continuar com eficiência.
Um dos maiores argumentos lógicos do Kanban é que o tempo demandado para se entregar uma feature é muito menos o tempo de trabalho das pessoas, mas sim muito mais o tempo da tarefa parada.
As estimativas de tempo de esforço pouco reflexo têm na entrega final, pois, o que mais vai afetar a data da entrega será o tempo nas filas, de DevOps, de QA, de espera da Sprint, de espera para alguma integração.
Tomando uma Sprint de 2 semanas.
E finalizando uma tarefa/funcionalidade na 1a semana.
Se eu assumir que farei o deploy no final do Sprint.
Automaticamente estou deixando uma tarefa parada empilhando por 2 semanas.
Usando o Scrum, trabalhando nas estimativas de esforço de trabalho na tarefa,
e esquecendo de medir os Sprints, a estimativa perde totalmente o valor.
Se acrescentarmos nisso, todo o trabalho para medir o esforço de tarefas,
o planning que nunca bate, as estimativas que sempre dão errado e precisam de
reajustes, chegamos a conclusão que essa medição padrão adotada no Scrum
é no mínimo ineficiente.
O fluxo é na perspectiva do cliente e não na visão da engenharia, nem da equipe, mas sim, na entrega de valor ao cliente.
Muitas vezes você entrega muitas funcionalidades, porém, vai para um repositório, no fim, isso não tem valor.
Kanban não é orientado a equipes, é sobre serviços, é pegar o que o cliente, melhorar o processo, entregar,
mais rápido, com o objetivo de entrega de valor.
As pessoas focam demais no esforço, estimam que a tarefa terá 2 dias de esforço.
Mas ninguém no projeto avalia que essa tarefa ficará 10 dias na fila.
As filas são o ponto cego, é aquilo que ninguém está olhando.
O foco não pode ser no esforço, na estimativa para concluir a tarefa, mas sim na entrega de valor ao cliente, esse sim é o prazo que afeta o projeto, que afeta quem financia e o maior interessado, o cliente.
Kanban aponta que para você ser previsível você não precisa de estimativas,
você precisa de métricas de observação, para tê-las, você precisa medir,
precisa de histórico, precisa de dados coletados, e com isso, você vai
conseguir fazer previsões futuras.
Você deve priorizar:
Minimizar o tempo médio de recuperação nas falhas.
Ao invés de focar em:
Maximizar o tempo entre falhas.
É melhor ter alta capacidade para se recuperar de um erro, do que ser muito blindado e precavido a ponto de não falhar.
É mais importante cair e recuperar rápido do que não cair.
Porque fazendo isso você vai ter menos obsessão em postergar as alterações, vai ter entregas mais contínuas, vai minimizar o tamanho do pacote final.
Terá um fluxo mais contínuo.
Kanban não é orientado a times, mas sim a serviços.
Kanban não exige times auto-organizados.
As empresas separam a equipe de manutenção da equipe de inovação geralmente é para o framework ágil deles funcionar, e poder entregar novas features com mais agilidade.
O problema é que o cliente quer novas funcionalidades, mas ele também quer as manutenções.
Muitas vezes manutenção é até mais importante.
No Kanban você pode separar o quadro em raias, e na raia de inovação 80% da capacidade, e na raia de manutenção 20%
Para usar Kanban você precisa pensar, o Kanban apenas te apresenta o que pode ser melhorado, o que precisa mudar, as coisas que estão erradas, e a responsabilidade e a iniciativa para alterar é tua, Kanban não é metodologia, não é framework, é um conjunto de práticas.
Você tem que passar para o cliente a liberdade dele determinar o que ele valoriza mais, a correção de um bug ou a introdução de uma nova feature.
Diminuir a variabilidade, uma das coisas que colaboram para ser mais assertivo na previsibilidade, é ter uma variabilidade menor no tamanho das atividades, o objetivo é tentar criar uma uniformização do tamanho das tarefas, as agrupando, ou de outra maneira.
O trabalho do século 21 tem variabilidade inerente O Kanban não é um método descontrolado, o Kanban pode parecer não ter uma cadência fixa, não ter uma forma de dizer como a pessoa vai entregar, etc. Mas isso é uma suposição errada.
A cada trabalho na área do conhecimento é algo novo, cada tarefa, cada projeto é algo que você nunca fez antes, e isso tras a variabilidade, não é possível a eliminar com a repetição.
Dentre as várias causas raízes da variabilidade, uma das principais são as filas.
As empresas precisam de lideranças, de gestores, e a visão de organizações horizontais e equipes auto-organizadas muitas vezes exagerada pelos métodos ágeis, podem trazer de nocivo um viés em que toda decisão deve ser tomada no consenso de todos, e isso pode jogar a liderança no escanteio.
Sim, todos gerenciam, mas deve haver hierarquia bem definida e com regras:
"gestor é todo aquele que tem condições de tomar uma decisão
a respeito de algo que precisa de alguém para encaminhar"
- Peter Druger
Equipes sempre serão heterogêneas:
nada mais desigual que tentar tratar pessoas diferentes de forma igual.
O júnior não pode, não deve, e geralmente nem terá desejo de tomar direção, ele precisa ser direcionado.
Um problema que pode ocorrer com a adoção de equipes auto-organizadas é o líder ser forçado demasiadamente a delegar, o que pode incorrer em delargar.
"Proatividade" e "Autoresponsabilidade" são práticas obrigatórias para qualquer profissional.
"Quando todos concordam, é porque ninguém está pensando"
Numa empresa de conhecimento, você não contrata braço, você contrata cabeças.
Não é possível acelerar uma gravidez com 9 mulheres, buscando um parto em 1 mês.
Do mesmo modo que querer adicionar diversos programadores num projeto em andamento.
Adicionar pedreiros pode agilizar uma obra, adicionar bombeiros para desbloquear uma região afetada por um furacão pode acelerar e muito a tarefa.
Mas numa profissão que envolve adaptação, aprendizado in-loco com um componente da equipe como instrutor, interação constante, trabalho em equipe como base, e até mesmo uma forte conexão entre equipes, não funciona adicionar programadores sem o impacto inicial que será enorme, além da provável perda de eficiência do mais sênior, e da equipe de DevOps por talvez estar os sobrecarregando.
PDCA de 1951, obra Kaizen de Masaaki Imai
Brainstorming
Mary and Tom Poppendieck
Lean Software Development
O Sistema Toyota de Produção: Do Ponto de Vista da Engenharia de Produção
Lean é um produto, é o Sistema Toyota empacotado.
O Kanban é um conjunto de práticas, o ideal é melhorando o processo da empresa aos poucos, passo a passo.
Não faça tudo de uma vez, faça de forma evolucionária.
O KMM vem dar resposta a quatro principais necessidades na utilização do Kanban:
- Obter uma melhor compreensão do estado atual da organização - do todo, dos seus produtos e serviços, e não apenas do time.
- Encontrar a prática apropriada para guiar a evolução - sabendo onde está, definir a próxima prática a aplicar. Para não trazer algo demasiado simplista que a organização já aprendeu, ou tão complexo que não vai conseguir lidar.
- Evoluir intrinsecamente a cultura e performance da organização - essa é a divergência principal do CMMI. O objetivo não é ter um selo de nível x do KMM, é de fato ter uma evolução de cultura e de resultados na empresa.
- Medir e controlar o progresso da transformação da organização - dar visibilidade do que está acontecendo e alinhar as expectativas.
O KMM surge assim para prevenir os dois modos de falha na adoção do método:
1- Passar do ponto:
– Plano de transição ambicioso
– Desenhado pelo cara mais esperto da sala
– Muita coisa, muito cedo
– Ambiente não está preparado
– Resistência a mudança
– Abandono
2- Achar que já está bom:
– Conseguimos implantar o Kanban
– Focado apenas no time
– Alívio da sobrecarga
– Melhorou a transparência
– Melhorou a colaboração
– Kanban trouxe o que precisávamos
É a união da cultura, práticas e resultados que diz qual o seu nível atual de maturidade.
Por exemplo, não basta ter todas as práticas do nível 3, se a cultura não acompanhar e muito menos os resultados.
E tem algumas práticas de transição e práticas de consolidação que também precisam ser seguidas antes de se assumir no nível seguinte.
Pouco a pouco, de maturidade em maturidade, a gente vai evoluindo e deve buscar no mínimo o nível 4.
O ponto é como provocar a melhoria.
Tem um modelo estruturado, tem uma forma de entender onde está e tem uma forma de enxergar qual o próximo passo.
A maturidade está intimamente relacionada com a cultura (como vivemos), as práticas (como fazemos) e os resultados (o quanto somos efetivos).
Na maturidade cega, ou zero, a pessoa ainda não tem consciência do que está à sua volta.
É uma cultura baseada em conquistas individuais.
As práticas são focadas em tarefas e existe apenas a visualização do trabalho do indivíduo.
E em termos de resultados basicamente é contar com a sorte.
Se aparecer algo diferente no mercado, você não está observando.
É muito perigoso. Não está adequado com o momento. Só sabe o que cada um está fazendo e não tem isso visível para todos.
A maturidade 1 é focada no time.
Você começa a ter uma cultura de colaboração, de iniciativa e de transparência.
Em relação às práticas, a gente já começa a ter algumas políticas explícitas básicas, tem um kanban de time, já consegue visualizar o trabalho, o fluxo passando, tem um limite de WIP por pessoa e kanban meeting.
A sugestão do KMM é ter cuidado com esse foco de time.
Na maturidade 2 o foco é no cliente, você sabe o que está entregando para o usuário.
Deixa de olhar para tarefas dentro de um Board e começa a olhar para resultados, aquilo que está gerando valor no final de todo um workflow.
Visualização do workflow, entendimento dos tipos de atividade que o cliente necessita, métricas de fluxo, gestão de impedimentos, gestão do WIP, revisão de políticas.
Os resultados ainda são inconsistentes mas com processo azeitado, tem um discovery e um delivery de Kanban, o fluxo end-to-end e uma certa rotina atrelada dentro da organização como um todo.
Relativamente às práticas já existe uma visualização de dependências, Falhas x Valor, análise de risco, previsibilidade, SLA e datas alvo, e critérios.
Há resultados de curto prazo, foco no cliente, atendimento de expectativas, mas ainda é economicamente inconsistente.
É preciso ter consciência que tem muita coisa para evoluir.
“É a organização que amadurece com seus processos, e não o Kanban que amadurece na empresa”
Para melhor entender o que é e qual o valor de um modelo de maturidade, imagine o cenário de um bartender durante a carreira dele. No início, ele sabe como servir as bebidas que já vêm prontas. À medida que o tempo passa, vai adquirindo experiência e aprende a fazer as bebidas mais clássicas e pedidas. E aí, conforme testa e ganha conhecimento e senioridade, entra na arte de criar cocktails e receitas por ele mesmo. É um processo de evolução. E o modelo de maturidade vem apoiar justamente nisso. Quebrar em níveis, entender onde eu estou no momento e qual a prioridade em seguida, a próxima capacidade a treinar.
Esse é o verdadeiro valor de um modelo de maturidade. Identificar o seu nível atual e o que precisa trabalhar para melhorar. Em todos os níveis de maturidade.
Olhando para outros modelos de maturidade, tem alguns que criaram uma reputação ruim, por exemplo o CMMI. Além de divergir de um mundo em constante mudança, acabou trazendo uma questão de certificação para os níveis. Isso fez com que as empresas tivessem mais interesse em certificar para cada um do que realmente entregar mais resultados. As certificações levaram à competição para ser o melhor e corromperam os valores essenciais.
Um modelo de maturidade deve ser visto como uma caixa de ferramentas para seguir passos e alcançar resultados. Não como um fim em si mesmo.