O nosso Sistema Kanban – Uma experiência Lean para equipes de sustentação

A Motivação

Há cerca de um ano, iniciei um desafiador trabalho de coaching em Agile para uma instituição financeira/bancária. De forma que como é uma empresa relativamente grande, têm nos permitido usar ferramentas diferentes para resolver problemas específicos, um exemplo disso é que usamos Scrum para projetos desenvolvimento de software e algumas práticas da FDD(Feature Driven Development) para engenharia e gestão de requisitos.

Um das áreas com qual eu atuo, é uma equipe de sustentação de produtos (suporte) que atende a vários clientes internos diferentes, com demandas (novas funcionalidades e correções) totalmente diferentes e principalmente numa necessidade de ritmo totalmente independentes da outra.

Dessa forma, simplesmente chegou-se a conclusão de que: Não era possível congelar o escopo de trabalho para uma iteração e também não era benéfico para os clientes que eles ficassem esperando com um estoque de desejos (backlog), ou seja, não se podia ter TimeBox baseado em iterações!

Uma luz no fim do túnel

Como não tínhamos um cenário favorável ao Scrum, desenvolvemos então uma intuição que nos levara em direção ao Lean para essa equipe, principalmente imaginando que ferramentas como o Kanban e Andon poderiam nos ajudar.

Mas foi durante uma conversa de boteco com o meu amigo Alisson Vale num Chopp Ágil aqui em Brasília, que pudemos olhar para a sua experiência com Sistema Kanban e ver como poderíamos ter resultados muito satisfatórios também com a aplicação de algo parecido para essa nossa equipe de sustentação.

E como funciona um Kanban?

Antes de prosseguir, vamos entender um pouco do que se trata um Kanban, para isso, é importante saber que em qualquer sistema de produção, um dos principais objetivos de um kanban é:  Através de sinalizações, amortecer as demandas que entram do processo e estabelecer um fluxo contínuo (e puxado) de entregas unitárias.

O principal desafio então é o balanceamento das demandas com a capacidade de trabalho da equipe, dessa forma, o Kanban acontece exatamente na sinalização de que quando houver capacidade disponível, podemos então puxar uma nova demanda para dentro do sistema.

Esse fluxo se baseia no sistema puxado (pull system), para evitar ao máximo a existência de grandes estoques de demandas em espera, estimulando assim que se racionalize de forma enxuta o sobre as atividades do seu sistema de produção,

O início de nosso sistema Kanban

Antes de iniciar diretamente em nosso quadro para colocar o Kanban, compreenda que nessa empresa já tínhamos todo um movimento forte em direção da Agilidade, de forma que muitas equipes (inclusive essa de sustentação), já estavam iniciadas culturalmente a trabalhar naquilo que o TPS (Toyota Production System) chama de “Gestão Visual”, ou seja, ambientes informativos e dinâmicos orientados ao contexto de trabalho da equipe, de forma que esse ambiente funciona com um Radiador de Informações.

Dessa forma, conseguimos alinhar aquilo que acreditávamos ser suficientemente bom como um fluxo de trabalho, assim nosso KanBan ficou norteado a sinalizar os seguintes elementos e atividades do processo:

  • Área de amortecimento baseado em assuntosIsso se tornou bem interessante para alocar as demandas que entram numa espécie de fila agrupada por temas (produtos) que os membros da equipe podem atender.
  • LeadTimeAdotamos o conceito de LeadTime  com o objetivo conhecer o tempo que uma demanda levou para ser entregue ao seu cliente, a partir do momento que ela entrou no sistema.

  • Classificação por tamanho de cada demandaVisando criar um mecanismo que atuasse como base para ajudar a conhecer a capacidade do sistema, passamos a classificar cada demanda de acordo com os seguintes sentimentos de tamanho: P – Pequeno, M- Médio e G- Grande. Isso nos possibilita sabermos nosso LeadTime por tamanho, o que é muito útil para priorizar e estimar uma nova demanda no sistema.
  • Valor da demandaPara estimular um critério de priorização, trabalhamos com uma categorização bem simples para identificar quando uma demanda é um: I – Investimento (Atividades que agregam valor ao produto já existente), C – Custo (Correção de defeitos) e A – Atendimento (Atividades que não têm ligação direta com os produtos).
  • Slots individuaisComo não é uma equipe reunida em torno de um único projeto, mas sim uma equipe de sustentação para vários clientes, vários produtos e várias demandas; Cada pessoa está comprometida com uma meta de entrega diferente, dessa forma, precisamos criar espaços (slots) que identificam  área de trabalho cada membro da equipe.
  • Definição de WIP (Work In Process)Um grande desafio nessa equipe era diminuir o desperdício gerado pela multitarefa que permitia a troca de demandas durante a execução e gerava uma grande sobrecarga de atividades, assim, exercitando o nosso senso de Heijunka, evidenciamos claramente onde está se tentando desenvolver mais de uma demanda ao mesmo tempo. Para isso, criamos sinalizações referentes a impedimentos e andamento em cada marco (milestone) necessário para a entrega de uma única demanda, dessa forma, fica muito visível se algum membro está se sobrecarregando e com isso, prejudicando a sua capacidade de entrega.
  • ImpedimentosComo essa equipe já estava bem acostumada em experiências passadas com Scrum a sinalizar e remover impedimentos, resolvemos manter esse comportamento nesse sistema Kanban, só que agora evidenciando ainda mais que a quantidade e a duração de um impedimento, atuam diretamente como uma perda no processo de desenvolvimento para uma referida demanda.
  • Reunião DiáriaEstamos praticando Reuniões Diárias de no máximo 20 minutos, como um importante instrumento de comunicação, integração e alimentador da importância do KanBan. Essa reunião é bem dinâmica e segue o modelo do Scrum onde cada membro compartilha: O que fez desde última reunião? O que irá fazer até a próxima? E se está com algum impedimento no andamento de determinada demanda?

Veja então na figura abaixo, a visão geral desse quadro de KanBan:

Visão Geral do Kanban

Visão Geral do Kanban

Resultados

Para expressar um pouco dos resultados desse sistema KanBan, veja qual a opinião de  Cristian Couto Ramos que é coordenador dessa equipe:

Estamos ganhando uma maturidade muito boa na organização do trabalho de nossa equipe, o que no futuro nos permitirá inclusive automatizar nosso KanBan em algum software, porém, hoje já estamos colhendo bons frutos em nossa comunicação e visibilidade.

Além dessa  integração, visibilidade e comunicação citadas por Cristian no parágrafo acima,  hoje já temos um bom balanceamento da carga de trabalho e conseguimos proteger o sistema contra a maioria das variações negativas que geravam atrasos e perdas nas demandas.

Temos um ganho cultural muito interessante, pois como essa equipe atinge todas as áreas dessa empresa, a filosofia Lean, acaba também se disseminando por si só. Dessa forma, muitas outras equipes estão criando modelos de desenvolvimento baseadas nessa nossa forma de trabalho.

Estamos conseguindo escalar a aceitação e o entendimento da mecânica do sistema KanBan para outras gerências e superintendências, que têm proporcionado uma construção em longo prazo de uma cultura Lean (enxuta) nessa organização.

E por fim, claro que ainda há muita coisa para melhorar nesse cenário, contudo, através dessa padronização na forma de trabalho da equipe, seu processo pode ser observável e com isso ter de fato um ambiente onde seja possível melhorar continuamente. Portanto, aguarde novos fatos futuramente sobre essa nossa experiência.

Sobre o autor:

Manoel Pimentel Medeiros, É Engenheiro de Software, com 15 anos na área de TI, atualmente trabalha como Coach em Agile, Lean e TOC para empresas do segmento de serviço, financeiro e bancário. É Diretor Editorial da Revista Visão Ágil e Editor Chefe da InfoQ Brasil, Já escreveu sobre agile para importantes portais e revistas do Brasil e exterior e Também palestrou em eventos nacionais e internacionais sobre agilidade. Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.

Contatos: manoel@visaoagil.com

13 thoughts on “O nosso Sistema Kanban – Uma experiência Lean para equipes de sustentação

  1. Olá Manoel,

    Achei muito legal essa Visão Geral deste Kanban.
    Aqui na empresa trabalhamos com SCRUM e com a participação do time de teste nos projetos tivemos que fazer algumas adaptações no Quadro Kanban que estão ajudando bastante. Por exemplo, antes tínhamos os seguintes “status”: Itens, Tarefas, Em Andamento e Pronto, agora fizemos uma adapatação e temos: Itens, Tarefas, Em Andamento (codificação), Pronto para Teste, Análise/Design de Teste, Em Execução (Teste) e PRONTO. Ficou bem melhor e temos uma Visão Geral onde o Time sabe exatamente como estão as atividades, incluindo os impedimentos.

    Novamente, belo post!!!

    Até+,
    Quezada

  2. Olá Manoel,

    fiquei interessado no mecanismo de “slot individual” que vocês estão utilizando. Pelo oq vi na foto do quadro em cada etapa do processo vc possui slots p/ cada um dos membros da equipe, correto?
    Desta forma vc acaba tendo um quadro Kanban por profissional é isso? Pela experiência q vcs estão tendo isso de alguma maneira atrapalha a visão sistêmica (todos profissionais + todas as demandas) do processo? Os indicadores (lead time principalmente) não acaba ficando “pessoal”?

    P.S. Caso vc entenda q seja melhor conversarmos em um fórum, lista de email ou em pvt por favor é só avisar oks?

    • Olá Leandro, tudo bem ?
      Falei sobre isso no seguinte trecho:

      Como não é uma equipe reunida em torno de um único projeto, mas sim uma equipe de sustentação para vários clientes, vários produtos e várias demandas; Cada pessoa está comprometida com uma meta de entrega diferente, dessa forma, precisamos criar espaços (slots) que identificam área de trabalho cada membro da equipe.

      Pois como você pode observar não há uma Sprint ou iteração, portanto não há uma meta única para a equipe. O Fluxo simplesmente é: Demanda entrando, demanda saindo e cliente Feliz!

      Abs,

  3. Manoel, fiquei muito interessado nesse sistema Kanban! Acredito q ele pode ser muito útil na equipe onde trabalho, que se encaixa exatamente neste perfil de sustentação. Tenho duas perguntas:
    – vc pode explicar um pouco melhor o quadro, talvez criar um artigo só pra isso? Ou estou precisando ler alguma referência para entedê-lo melhor?
    – Pode me indicar material, links, livros, etc. para q eu possa aprofundar o assunto?
    Abraço,
    Daniel

  4. Grande Manoel! Parabéns pelo excelente trabalho que vem realizando e por todas as contribuições que você faz para a comunidade de desenvolvimento de software. Achei todos os esses conceitos que você apresentou muito bacanas,vou estudá-los com maior profundidade e analisar que pode ser aplicado para a minha equipe… Grande Abraço.

  5. Olá Manoel.

    Pelo que entendi ao final de cada demanda concluída, um patch do sistema é liberado, correto ?

    Se a granularidade das demandas for pequena, um alto número de deploys em intervalos curtos de tempos não causa indisponibilidade do sistema ?

    Gostaria de saber como vocês lidam com essa questão.

    Um abraço

    • Olá Cláudio, tudo bem?

      Normalmente os “paths” são pequenos e em curtos intervalos sim (pois são correções ou pequenas evoluções), porém não há esse problema de indisponibilidade, pelos seguintes motivos:
      – Esses “paths” não são apenas para um único produto;
      – Existe uma arquitetura das aplicações muito boa e super escalar (são aplicações bancárias);
      – Os deploys são realizados em horários específicos de forma totalmente automatizada;

      ok?

      Espero ter ajudado.

      Abs,

  6. Excelente! Finalmente um artigo sobre a utilização de métodos ágeis na vida real (pelo menos a “minha” vida real!)

    Sou lider de equipe de desenvolvimento em uma das principais fornecedoras de ERP do Brasil e temos exatamente esse quadro: poucos produtos e manutenção contínua (novas features, correções, correções da legislação, aderências em novos clientes). Não temos como planejar um backlog pois o dinamismo de novas requisições é muito grande.

    Um abraço!

  7. Manoel,

    Aproveitando, gostaria de fazer uma pergunta: em um caso desses (sustentação) onde você tem um único produto e vários clientes utilizando-o em vários estados do Brasil, como você vê a figura do Product Owner?

    Eu não tenho como interagir com os clientes, mas nossos Analistas de Negócio interagem. Eu tenho a visão de que poderia determinar como sendo Product Owner o analista de negócio já que ele tem conhecimento do processo do cliente.

    Como você vê isso?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s