O objetivo deste artigo é oferecer uma visão enxuta sobre o Kanban, apresentando direcionamentos iniciais sobre suas 6 práticas gerais.
As 6 práticas gerais do Kanban
Desenvolvido por David J Anderson, Kanban é um método que nos dá visibilidade e entendimento sobre o trabalho que estamos executando, utilizando para isso uma abordagem evolucionária.
Tendo como pilar a premissa: “comece pelo que se faz hoje”, o Kanban não promove uma desconstrução do fluxo de trabalho, papéis e regras atuais, muito pelo contrário, o método se apresenta como uma opção para entender como o trabalho já é realizado, de forma a gerenciá-lo de maneira mais eficiente, conduzindo o mesmo a um ciclo evolutivo constante.
O “trabalho do conhecimento”, antes intangível, ganha vida com o Kanban e para fazer isso nos valemos de um kanban system, ou seja, um flow system onde estabelecemos uma limitação de Work in Progress (WiP) através de representações visuais (como cartões indicando a limitação de entrada de trabalho no sistema), além da definição de uma linha de commitment (comprometimento) e uma linha de delivery (entrega). A imagem 1, logo abaixo, demonstra uma representação de um flow system e de um kanban system.
O método Kanban possui 6 práticas gerais utilizadas para gerenciar kanban systems.Dessa forma, é possível mapear o quanto um time ou organização se aprofunda em cada uma dessas práticas, conforme imagem 2.
1. Visualize
2. Limit work in progress
3. Manage flow
4. Make policies explicit
5. Implement feedback loops
6. Improve collaboratively, evolve experimentally
O nível de maturidade de implantação e utilização do Kanban fica ainda mais claro com a definição do “Kanban Maturity Model”,que será explorado em outro artigo.
Sobre as práticas gerais:
1. Visualize
A utilização de kanban boards (quadros) é uma das formas de visualizar o trabalho que está sendo realizado. Acima de tudo, não há uma definição prescritiva no método sobre como ou onde (parede, meio eletrônico e etc.) exibir essas informações, o necessário é realizar um mapeamento do fluxo de trabalho entendendo profundamente o mesmo. Veja na imagem 3, um exemplo de kanban board.
2. Limit work in progress
A determinação de uma limitação de trabalho em andamento (WiP) faz com que tenhamos um sistema “puxado”, ou seja, só temos a entrada de um novo item quando a capacidade de trabalho se torna disponível, conforme pode ser observado na imagem 4.
3. Manage flow
Parte fundamental da aplicação do Kanban é identificar como maximizar o fluxo de valor entregue pelo sistema. Para que isso ocorra precisamos ter visibilidade do impacto da “não entrega” para cada tipo de item no nosso fluxo de trabalho. Para identificar o que chamamos de “Cost of Delay (CoD)”, ou seja, o custo da espera por um item não ser entregue, precisamos ter um mapeamento dos 4 arquétipos previstos no Kanban (imagem 5) a partir dos quais são derivadas as classes de serviço que utilizamos na nossa rotina de trabalho.
Os quatro arquétipos
Expedite (ou “Silver Bullet”):
Essa classe foi herdada da indústria de manufatura, trata-se de um item com um custo de espera que cresce de maneira exponencial, um item que precisa ser atendido prontamente para o cliente. A atuação em itens expedite gera impactos no atendimento de outras classes de serviço, tendo em vista que no momento que um item deste arquétipo entra no fluxo, deve ser atendido prontamente. Recomenda-se a identificação de uma raia ou cor específica para esse tipo de classe, assim como demonstrado no fluxo acima pela cor roxa.
Fixed Date:
Quando existe uma data fixa para um item, uma janela intransferível de entrega. Esse tipo de demanda ocorre muito, por exemplo, no setor financeiro quando temos uma normativa do Banco Central com uma data fixa para adequação de algum ponto, caso contrário, há uma punição. Outro exemplo é quando entregamos um item para a área educacional, existe uma janela para o início do ano letivo, portanto, a não entrega do item representa a perda de oportunidade de negócio. A data alvo de um item como este sempre deve estar visível.
Standard:
A maioria dos itens se encaixam nesta categoria, uma boa prática neste cenário seria a determinação de um “Service Level Agreement” (SLA) para a classe. Uma técnica bastante utilizada para tal é a determinação do “t-shirt size” (tamanho da camisa), ou seja, quantos dias levam para que um item de determinado tamanho seja atendido em média.
Exemplo:
P – 2 dias
M – 5 dias
G – 7 dias
Intangible:
Um item do tipo Intangible não tem seu “Cost of Delay” tangível em um horizonte de curto prazo. Por exemplo: Se utilizamos um determinado banco de dados que possui suporte do seu distribuidor até 2020, a migração para uma versão mais atual não é uma questão latente em 2016, por exemplo. Assim, com o passar do tempo esse item ganha relevância e seu peso fica mais evidente.
4. Make policies explicit
A definição de políticas articula o processo com o qual estamos trabalhando, criando regras para as ações realizadas ao longo do nosso fluxo de trabalho. As políticas devem sempre estar visíveis, bem definidas e facilmente alteráveis. Veja representação esquemática na imagem 7. Uma boa forma de posicionar visivelmente as políticas seria aplicá-las entre os estados de transição do fluxo.
Exemplo:
Para que um item migre do status de “Desenvolvimento” para “Aguardando testes”, as seguintes regras atreladas à política devem ser cumpridas:
-Code Review realizado;
-Teste básico realizado pelo desenvolvedor.
5. Implement feedback loops
As oportunidades de feedback são momentos de sincronização necessários para controlar e evoluir o processo. Assim, cada oportunidade dessas traz à tona um conjunto de objetivos a serem alcançados e possuem cadências sugeridas. A imagem 8 traz um resumo das oportunidades de feedback e seus respectivos relacionamentos.
Strategy Review: O nível mais alto de Review, serve para alinhar a estratégia da organização baseado nas informações dos clientes e do mercado.
Service Delivery Review: Reunião focada em avaliar a performance do time em relação ao que o time se comprometeu. Nesse encontro avalia-se métricas relacionadas ao cliente, qualidade, lead time, como as classes de serviço foram trabalhadas, por exemplo.
Operations Review: Similar ao Service Delivery Review, contudo, cobre uma fatia maior da organização. Analisa se os serviços entregues globalmente estão aderentes às expectativas dos clientes.
Risk Review: Utilizada para promover discussões sobre os riscos associados à determinadas tarefas. Por exemplo: Adoção de uma nova classe de serviço.
Delivery Planning Meeting: Reunião importante para orquestrar as entregas de acordo com a necessidade do cliente.
Kaban Meeting: Reunião diária de sincronização, recomenda-se observar o kanban board durante esse momento, avaliando o andamento, falando sobre impedimentos e verificando se as limitações de WiP estão sendo respeitadas.
Replenishment Meeting: Reunião para mover itens para a área de “commitment”, além de preparar itens para entradas futuras. Ademais, a seleção e Refinamento de itens são o alvo desse momento.
6. Improve collaboratively, evolve experimentally
Kanban é fundamentalmente um método para promover melhoria. Portanto, não há um ponto de chegada nesse processo e o mesmo usa o paradigma do fluxo Lean (enxergar o trabalho como um fluxo de valor).
Toda vez que temos um ponto no processo que recebe mais trabalho do que tem capacidade de dar vazão, interrompendo a fluxo de valor, temos então um gargalo (bottleneck).
Ao identificar os gargalos mencionados acima, precisamos iniciar logo depois um conjunto de ações para eliminar os mesmos. Temos um conjunto variado de ações possíveis, como por exemplo:
- Alterar uma regra em uma determinada política;
- Movimentar pessoas da equipe para auxiliar em uma determinada atividade;
- Ampliar a equipe;
- Incluir uma etapa ao processo;
- Reavaliar alguns pontos do workflow.
Em conclusão, desejo ter contribuído para o seu conhecimento relativo ao método Kanban! Existe uma vasta bibliografia recomendada e muito informação disponibilizada pela LKU (Lean Kanban University). Recomendo aqui também a leitura de um artigo sobre um framework igualmente útil no contexto do desenvolvimento de software em sua empresa: o Scrum.
Por: Leonardo de Oliveira Pinto Francisco, Agile Master na Invillia.
Referências
ANDERSON, D. J. Kanban: Successful Evolutionary Change for Your Technology Business. Washington: Blue Hole Press, 2010.
No item 6 onde tem o link para a LKU faltou uma letra na palavra “kanban”