Kanban

O sonho, o fluxo e o pássaro

Em alguns Agile Tour, apresentei em quase todas as cidades o meu workshop, buscando o estado de fluxo. O que se segue aqui é uma descrição do mesmo, para que você também o possa aplicar em sua equipe, talvez levando um pouco mais de entendimento sobre Lean-Kanban ou ao menos, fazendo-os pensar sobre o assunto.

No começo é necessário lembrar de uma lenda japonesa que diz que se você tiver um sonho, algo que você deseje muito, basta produzir 1000 (mil) tsurus (pássaros ou garças de origami) e pendurá-los em uma cerejeira que esse desejo é atendido. Bom, eu desejo uma Harley-Davidson, qualquer modelo (preferencia pela FatBoy), portanto peço aos que atenderam para esse workshop que me ajudem.

O processo para fabricar o tsuru é bem simples e não exige nenhum conhecimento prévio de dobradura. Ele pode ser apresentado nas sete etapas que podem ser observadas nas fotos abaixo:

tsuru_step1 tsuru_step2 tsuru_step3 tsuru_step4 tsuru_step5 tsuru_step6 tsuru_step7 tsuru

Assim, dividido em 7 etapas distintas, necessita-se de uma equipe de 7 pessoas no mínimo para executar essa atividade. Organize-os em uma sequência de mesas, mais ou menos como uma linha de produção.

IMG_2932

DSCN1674

Além dos papés de quem vai efetivamente executar o trabalho, precisamos de pessoas que monitorem o processo, observem-o e foquem em aperfeiçoa-lo. Claro que os inputs podem vir de qualquer membro da equipe, mas se não houver com o foco nisso, equipes inexperientes podem ter dificuldade para gerir as mudanças no princípio. Assim, precisamos de uma pessoa para anotar os dados em duas planilhas, a primeira é bem simples, com um número para cada etapa em cada um dos ciclos. Nela devem ser anotados quantos itens ficaram em cada etapa ao final do tempo dado.

tsuru_tracking

Um último detalhe que as imagens não descrevem, o primeiro membro da equipe, aquele que corta o papel para ser um quadrado, deve anotar em qual ciclo/lote aquele papel foi cortado. Isso será usado na outra planilha onde vamos montar um gráfico de dispersão. Essa planilha é opcional (portanto a anotação também), somente para o caso de você querer ensinar sobre Lead time e quanto tempo as tarefas podem estar paradas dentro do seu processo. Eu costumo faze-lo direto no Excel, ferramenta excelente e necessária para esse workshop.

Muito bem, equipe treinada no processo, observadores a postos, trackers alinhados sobre o que deve ser medido, iniciemos o trabalho, que se realizará em ciclos de 4 minutos. Correndo o primeiro ciclo (ou sprint, iteração, o que você achar melhor) algumas disfunções já são visíveis. A primeira é que o processo está desbalanceado, com etapas muito simples e outras muito complexas. Isso visivelmente vai gerar gargalos, mas não podemos chegar no processo final ainda, então muita disciplina é necessária nesse momento. Outra observação que se pode fazer é que existem pessoas que tem mais afinidade com algumas atividades, outras com outras e ainda temos aquelas que não se adaptam a trabalhos manuais. Normal, não somos todos iguais e as diferenças, quando assumidas, devem ser respeitadas.

O ideal é executar o ciclo de desenvolvimento umas 7 vezes aproximadamente, dando sempre um tempo entre os ciclos para que as pessoas parem, reflitam e implementem modificações. Ao final, muitas equipes foram capazes de compreender aonde estão os seus gargalos e agir para tratá-lo. Já outras colocaram mais e mais recursos da platéia na equipe até perceberem que essa era uma das piores soluções. A seguir alguns dos gráficos gerados por essas equipes. Neles os gargalos ficam muito claros a partir de um tempo. Algumas equipes souberam lidar com seus problemas em tempo, outras precisaram de ajuda, ainda houveram outras em que nem com ajuda o tempo foi suficiente para resolver.

Uma coisa que pode se fazer para lembrar o quanto trabalho em progresso é ruim é, no meio do processo, lá pelo 4º ou 5º ciclo, avisar que o mercado mudou e não se interessa mais por pássaros, mas sim por aviões de papel. Isso fica especialmente evidente caso a equipe não tenha se preocupado em limitar o WIP (Work in progress) pois todo os itens começados e não acabados agora terão de ser ou jogados fora ou vendidos à preço de banana. De qualquer forma, sua produção teve um prejuízo.

Seguem alguns gráficos de equipes que realizaram esse workshop.

cfd01

cfd02

cfd03

dispersao03

dispersao05

dispersao01

Essa obviamente é uma descrição bem superficial, ao final ainda conversamos sobre teoria das restrições, como promover mudanças e outras observações que o público apontar.

O importante é que no final, todos perceberam a importância de observar o sistema como um todo, de tratar os gargalos de seu processo produtivo, como medir de maneira justa e ainda como a limitação de trabalho em progresso pode ser uma ótima opção para tudo isso.

Agile Tour 2014 – Missão cumprida!

LogoAgileTour2014Foi uma grande felicidade para mim. Esse foi o ano em que mais cidades tiveram o Agile Tour passando por elas. Em cada uma pude ver as pessoas felizes em receber um evento que fala de tecnologia, mas especialmente de pessoas e como trabalhar para que todas elas se sintam melhor em local de trabalho.

Iniciamos em Curitiba, depois São Paulo e então Campinas. Na sequência viajamos pelo interior do Paraná, para Cascavel e finalmente minha terra, Maringá. Outras cidades nos pediram eventos e vamos com certeza, com a força da comunidade (#AgilePower) fazer de 2015 um ano épico.

Em nome de toda a equipe organizadora, vai o meu muito obrigado a todos os participantes, palestrantes e patrocinadores que fizeram desse evento o grande sucesso que foi.

Todas as fotos, vídeos, grades e tudo o mais pode ser encontrado no site do evento.

Quando os rótulos não atendem às suas necessidades

ler-rotuloAntes de começar esse artigo, eu preciso esclarecer. Eu não pretendo que esse seja o compêndio definitivo tal qual um comparativo entre os principais métodos (ou frameworks, ou práticas) ágeis disponíveis hoje. Nem tampouco quer determinar se existe uma resposta definitiva para as suas preces em decidir qual é a melhor, ou ainda, qual dessas visões está correta. O objetivo aqui é mostrar o quanto queremos adaptar as soluções às nossas realidades, políticas e culturas, sem ao menos entender o porque de cada uma das propostas.
Continue reading

Agile Trends 2014 – foi show!

agile_trends_02 agile_trends_01 agile_trends_03Esse post nem é muito informativo. É um post para falar de um evento que foi muito bom, show de bola mesmo, por falta de adjetivo melhor para descrever. Vi várias talks muito boas, com gente de altíssimo nível. Outra coisa que chamou muito a atenção foi o nível das perguntas e o engajamento não só de quem foi como talker, mas para quem foi participar. Excelentes questões, elevando em muito a discussão. Adorei o formato, virei fã.

É claro, rever os amigos, fazer novos, tomar uma geladinha e ter altos papos pós evento ajuda em muito para fixar essa imagem de evento que vale muito ser lembrado.

Parabéns aos organizadores, nem vou citar um só para não ser injusto.

Nos vemos de novo no Agile Brazil.

Algumas fotos do evento no facebook