MISSÃO KANBAN - Parte I- MAPEAR O FLUXO DE TRABALHO ATUAL

Leandro Webster
7 min readJun 24, 2020

--

Dando sequência à série de posts Missão: Kanban (clique aqui para ler o primeiro post da série), hoje iniciaremos o relato dos encontros do time de desenvolvimento para construção do sistema Kanban. Os encontros foram escritos em em ordem cronológica, desse modo é possível acompanhar a evolução do time nos conceitos e atividades propostas e os resultados alcançados. Ao final de cada encontro, teremos uma pequena lista de aprendizados adquiridos. No post de hoje falaremos sobre o primeiro encontro, que teve como objetivo principal mapear o fluxo de trabalho do time.

Sempre bom recordar que a série Missão: Kanban está sendo compartilhada em cinco posts com publicação semanal e que este é o segundo post da série (a agenda de publicações completa com o link dos posts anteriores está disponibilizada no final deste post).

TENHA UMA BOA LEITURA!

ENCONTRO 1 — MAPEAR O FLUXO DE TRABALHO ATUAL

§ Tarefas

  • Mapear o fluxo de trabalho atual;
  • Dividir o fluxo de trabalho em upstream e downstream e definir o commitment point e os pontos inicial e final de controle;
  • Identificar os itens de trabalho.

§ Resultados esperados

  • Fluxo de trabalho definido com: upstream, downstream, commitment point e os pontos inicial e final de controle;
  • Itens de trabalho definidos e com seus ciclos dentro do fluxo de trabalho mapeados.

O Kanban é um método evolucionário, desse modo, conhecer e mapear o fluxo atual agrega mais valor ao time do que redesenhar o processo. Nosso primeiro passo nessa jornada é auxiliar o time na compreensão e definição do fluxo de trabalho.

Importante que esse exercício não seja feito apenas com o time, mas como um time. É importante que vejam que todos possuem participação no processo, mesmo que seja um workflow simples com etapas “To do”, “Doing”, “Done”.

MAPEAR O FLUXO ATUAL

Como o time estava trabalhando com o framework Scrum, já existia um fluxo estruturado e representado em board físico e eletrônico. O fluxo de trabalho estava mais focado na etapa de downstream, como demonstra a representação abaixo:

Como o fluxo atual já estava mapeado (e sendo utilizado), foi possível “pular” este passo e iniciar a preparação do time para a próxima atividade através da compreensão dos conceitos de upstream e downstream.

DIVIDIR O FLUXO DE TRABALHO EM UM FLUXO UPSTREAM E DOWNSTREAM E DEFINIR O COMMITMENT POINT E OS PONTOS DE CONTROLE (INICIAL E FINAL)

Para ilustrar ao time o conceito de upstream e downstream foi utilizada a imagem abaixo:

Imagem retirada do livro Essential Upstream Kanban | Patrick Steyaert

Upstream ou “Discovey Kanban” são as etapas do fluxo de trabalho que tem o objetivo de amadurecer e validar ideias antes de aplicá-las no mundo real.

Downstream ou “Delivery Kanban se refere à todas as etapas seguintes do fluxo de trabalho a partir do backlog de itens gerados no upstream.

Após a compreensão dos conceitos, chegou a hora de identificar no fluxo de trabalho atual quais colunas representariam a etapa de upstream e quais representariam a etapa de downstream. Neste momento foi possível ao time identificar também o commitment point (o momento dentro do fluxo em que o time de desenvolvimento entende que o item de trabalho está pronto para ser desenvolvido e se compromete com o item). Segue o resultado:

Durante o mapeamento do fluxo, o PO do time fez uma observação de grande importância para nosso processo: “acho que o upstream é um pouco maior”. Foi o gancho que precisávamos para a nossa primeira evolução dentro do fluxo de trabalho: detalhar a etapa de upstream. Veja bem: detalhar a etapa, não redesenhar o fluxo.

Para este detalhamento, utilizamos a ferramenta Mural (https://www.mural.co/), onde cada integrante do time recebeu pronto o fluxo de trabalho atual e desenhou um fluxo de trabalho, considerando as etapas de upstream e downstream conforme a sua visão. A ideia neste momento é trazer diferentes pontos de vista para o processo.

Mapeamento individual feito, iniciamos a etapa de compartilhamento, onde cada integrante apresentou seu fluxo aos demais com uma breve explicação. Após as apresentações chegou a hora de elaborar o fluxo de trabalho do time de maneira colaborativa. Nesse momento foi necessário decidir o ponto inicial e o ponto final de controle e visualização do processo, além de possíveis interações com os demais times da empresa. É importante tomar essa decisão (ponto inicial e final de controle) ainda no estágio inicial da implementação do Kanban.

Outro ponto levantado nesta tarefa é que o time não deveria enxergar o upstream apenas como um trabalho do PO, mas sim uma etapa do fluxo de trabalho e que o time deveria ser envolvido sempre que necessário, afinal, quanto mais tempo despendermos no upstream, maior será a qualidade do item de trabalho ao chegar no downstream.

O time optou por adotar uma visualização do fluxo de trabalho dentro da sua esfera política de controle, dando espaço para negociar novas maneiras de interagir com os parceiros imediatos fora dessa esfera de uma maneira compatível com o sistema puxado que estamos implementando.

Após a tarefa, o time alcançou o resultado ilustrado na imagem abaixo:

Com a definição do fluxo de trabalho, commitment point e ponto inicial e final de controle, iniciamos a identificação dos itens de trabalho.

IDENTIFICAR OS ITENS DE TRABALHO

Para a tarefa de identificação dos itens de trabalho recorremos mais uma vez ao princípio do “Comece com o que você está fazendo agora”. Sendo assim, primeiramente listamos todos os tipos de itens de trabalho disponíveis na ferramenta utilizada pela empresa (Azure DevOps), elencamos quais eram os mais utilizados pelo time e quais poderiam entrar no fluxo de trabalho. Em seguida, definimos o que cada item de trabalho representaria em nosso fluxo e qual seria a cor do post-it no board físico, chegando ao resultado abaixo:

Após a definição dos itens de trabalho, foi o momento de projetarmos o cartão para cada tipo de item para facilitar a auto-organização do time. Para chegarmos ao modelo de cartão abaixo, consideramos as informações disponíveis no card virtual do Azure DevOps.

Foi definido que a diferenciação visual de cada item de trabalho no board físico se dará pelas cores dos post-its (conforme quadro acima) e que a identificação do responsável pelo item se dará pelos avatares já existentes para os integrantes do time. Para o board virtual, a própria ferramenta fornece as informações necessárias.

Como é fundamental saber onde cada atividade começa e termina para que seja possível monitorar sua evolução, bem como a performance do processo, finalizamos a primeira etapa com o mapeamento do “ciclo” que cada item possui dentro do nosso fluxo. Abaixo temos o resultado desta dinâmica e o fluxo final definido pelo time:

APRENDIZADOS ADQUIRIDOS NO ENCONTRO

§ Começar pelo que já temos e evoluir o fluxo atual;

§ Upstream é um fluxo do time, não um trabalho do PO;

§ Limitar o controle do sistema Kanban para etapas em que o time tem poder de decisão. Não faz sentido controlar atividades de outro time;

§ Alguns tipos de item de trabalho podem não precisar de todos os passos do fluxo;

§ Projetar o cartão do item de trabalho para que ele tenha informação suficiente para facilitar auto-organização para puxar, e permitir que os membros da equipe tomem decisões baseando-se no tipo do item de trabalho e demais acordos;

§ Modelar o board do time conforme as decisões alinhadas na visualização do trabalho e acrescentar os itens que serão vistos nos próximos encontros.

Muito obrigado a todos que chegaram até o fim deste post, e até a próxima semana, quando falaremos sobre o 2º e o 3º encontro com o time.

AGENDA DE POSTAGENS

  • 17/06/2020 — Seção 1 (Idealizando a Missão: Kanban) - Leia aqui!;
  • 24/06/2020 — Encontro 1 (Mapear o Fluxo de Trabalho);
  • 01/07/2020 — Encontro 2 (Estabelecer as Classes de Serviço) e 3 (Tornar as Políticas Explícitas);
  • 08/07/2020 — Encontro 4 (Limitar o Work in Progress); e
  • 15/07/2020 — Encontro 5 (Gerenciar o Fluxo de Trabalho) e Seção 3 (Considerações Finais e Próximos Passos).

--

--

Leandro Webster

Agilist and Kanban Coach. Enthusiast in product development, UX, business and technology. Grêmio FBPA Supporter. Brazil.