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.

Estruturando a retrospectiva

Recentemente em um dos meus últimos trabalhos como coach precisei recomendar um modelo inicial para as retrospectivas. É claro que o ScrumMaster precisa pensar em maneiras diferentes para evitar que essa cerimônia importantíssima caia na monotonia, mas a primeira, para que se descubram os sabores (ou dissabores) de uma retrospectiva, pode ser o ponto mais importante de uma equipe ágil.
Acredito que o primeiro ponto que preciso tocar aqui é porque fazemos retrospectivas. Numa visão Lean mais xiita poderíamos pensar que tudo que não agrega valor ao produto, por consequência ao cliente, não deveria estar presente no processo. Mas se dermos uma rápida olhada ao que diz o último (mas não menos importante) princípio por detrás do manifesto poderemos observar:

Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Veja, faz parte do conceito de ser ágil pensar em maneiras de melhorar o como fazemos nossas coisas. Para mim, na verdade, o centro de “ser ágil” reside na evolução constante. Perceba que usei a palavra “constante” e não cíclica. Isso significa dizer que a evolução deveria ocorrer a todo momento. No instante em que se identifica um ponto de melhoria esse deveria então ser testado e tratado para que quem sabe no futuro faça parte do processo. Mas em um status inicial, equipes precisam de ferramentas para sistematizar sua melhoria. Mais do que isso, podemos dizer até que precisam de ferramentas para se disciplinar, tornar essa cerimônia um hábito e a partir daí sim buscar a evolução contínua. Até lá retrospectivas são muitas necessárias.

Tendo estabelecido o porque, vamos para o como. Muito do que eu falo sobre retrospectivas vem do livro da Diana Larsen e Esther Derby (Agile Retrospectives – making good teams great) pois sempre gosto da ideia de ter timeboxes definidos para cada atividade. De novo, isso disciplina e ajuda as pessoas a manter-se no foco. Assim elas dividem a retrospectiva em fases, como descrito à seguir:

ciclo_retrospectiva

Gosto muito dessa imagem pois tira um pouco da superficialidade de quem somente ouviu sobre a técnica proposta por elas e passamos a ver o ciclo completo. Isso ajuda muito a entender que mesmo retrospectivas, que ocorrem em ciclos, tratam de evolução contínua, pois o ciclo de melhorias nunca para. Assim, o que temos são cinco fases dentro da retrospectiva em si e mais outras que devemos ficar atentos no espaço entre uma retrospectiva e outra.

Set the stage

Momento no qual se explica como procederemos durante a retrospectiva, quais serão suas fases, quanto tempo cada uma levará, se serão necessários alguns acordos de trabalhos (work agreements). É o momento de colocar todos na mesma página para garantir a boa fluidez dessa cerimônia.

Gather Data

A fase da coleta de informações. Você deve criar mecanismos ou ambientes nos quais as pessoas se sintam seguras em relatar os fatos que ocorreram na última iteração. Você pode fazê-lo no momento da retrospectiva mas também pode ser feito de maneira contínua, ao longo do desenvolvimento. Pode ser usada uma técnica chamada timeline, onde você coloca em algum ponto do escritório um quadro que representa o seu ciclo (por exemplo, duas semanas, com um espaço para cada dia) e os membros da equipe vão até esse quadro e o preenchem com os eventos que acontecem no momento em que acontecem. Todo o fato que tiver impacto sobre o desenvolvimento deve ser relatado. Caso queira coletar os dados durante a retrospectiva, pode-se usar outras técnicas descritas no livro, como MAD/SAD/GLAD ou Plus/Deltas.

Generate Insights

Se a fase anterior era só para relatar o que aconteceu, nessa fase a ideia é ter ideias. Não tem ideia boba, a única indicação é que todos trabalhem para resolver os problemas mais do que para defender um ponto de vista. Após os presentes apresentarem suas ideias podemos passar para a próxima fase.

Decide what to do

Uma vez que sabemos o que aconteceu, que tivemos algumas ideias de como resolver, chegou a hora de pensar em quais dessas ideias podem virar ações concretas, coisas que podemos fazer para resolver o problema (ou melhorar o que estamos fazendo) já na próxima iteração. Perceba que aqui já não cabem mais abstrações, precisamos de ações que possam ser executadas por alguém, dentro do espaço de tempo que temos entre as retrospectivas. A técnica dos 5W2H pode ajudar a sistematizar essa fase.

Close the retrospective

Encerre relatando a todos as decisões tomadas, quem as executará, quais foram os problemas tratados e quando será a próxima retrospectiva.

Agora algumas dicas gerais

O foco da retrospectiva é a busca por soluções para problemas e melhorias no processo. Não é uma disputa de egos entre qual ideia é a vencedora ou mesmo que eu devo participar em todas as discussões, caso se deva escalonar em times maiores. O foco de todos os envolvidos deve ser sempre a melhoria do processo.

Outra dica importante é se criar um pequeno cronograma que pode ser apresentado no começo, na fase de preparação do ambiente. O próprio livro tem um exemplo.

cronograma_retrospectiva

Por último, mantenha o foco da equipe. Equipes grandes tendem a perder o foco em retrospectivas muito longas, portanto use os timeboxes a seu favor.

Espero que isso os ajude nas suas próximas retrospectivas.

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.

A sabedoria de Musashi

640px-Musashi_ts_pic
Estamos no Japão feudal, um tempo e local onde as pessoas buscavam fazer aquilo que lhes era atribuído buscando a máxima perfeição, tanto nos seus modos como em seus resultados. Muita coisa podemos aprender de lá. Nesse época, vivia por lá um homem chamado Miyamoto Musashi. Ele era um samurai.
Dentre diversos ensinamentos que esse sábio nos deixou, muitos podem ser aplicados a coisas do nosso cotidiano, inclusive, por que não, no desenvolvimento de equipes e pessoas de alto desempenho. Vou citar alguns aqui, extraídos do livro “Os cinco anéis”.

“There is nothing outside of yourself that can ever enable you to get better, stronger, richer, quicker, or smarter. Everything is within. Everything exists. Seek nothing outside of yourself.”

O paralelo que podemos fazer desse ensinamento seria que muitas vezes, pessoas, organizações, equipes buscam soluções mirabolantes e demandam que pessoas externas àquele grupo venham para lhe dizer obviedades. Ouça seu time, faça retrospectivas, sessões de brainstorming, a solução para seus problemas pode estar escondida dentro daquele cara mais tímido da sua equipe.

“Do nothing that is of no use”

Evite o desperdício. Desperdício em todas as suas formas. Mapeie o sua cadeie de valor e encontro as etapas em seu trabalho que realmente agregam valor ao seu processo produtivo. Reuniões inúteis, estoques sem propósito, processo sobrecarregados, defeitos, tudo isso é desperdício e deve ser evitado.

“You can only fight the way you practice”

Ou no português claro e atual, cada um no seu quadrado. É impossível para alguém opinar com propriedade sobre algo que não conhece ou mesmo que conhece apenas superficialmente. Só é possível dar testemunho (novamente, com propriedade) de algo que se viveu. Se me propor a falar sobre as experiências de outros certamente soará falso e minha credibilidade se porá a perder. É importante entendermos que um time deve ter dentro de si todas as habilidades necessárias para completar suas tarefas. Veja bem, o time, não o indivíduo. Aceitar que existem áreas de conhecimento que fogem ao meu domínio me permite aprender mais sobre elas e evitar problemas.

“To know ten thousand things, know one well”

Hoje muitas pessoas se gabam de seu conhecimento horizontal, conhecer muitas coisas mas todas de maneira superficial. Isso leva a diversas coisas das mais bizarras como um consultor, que foi treinado por uma consultoria, não fez cursos, não participou de eventos ou coisa semelhante e muito menos participa da comunidade para poder debater suas idéias. Tal “profissional” afirma coisas como que o papel do ScrumMaster deve ser rotativo, sendo trocado o papel entre os membros do time. Esse, entre outros absurdos, são apregoados por profissionais rasos, que não buscam aprofundar o conhecimento em nada e dizem conhecer tudo que há para se conhecer. Caso você queira ser um profissional com alto conhecimento horizontal isso não é negativo. Mas é importante que antes de se tornar um generalista, seja especialista em pelo menos uma! Escolha uma área que você realmente gosta e aprenda essa pra valer! Depois vá e amplie seus conhecimentos, mas não sem antes ser reconhecidamente um especialista em alguma área.

“You must understand that there is more than one path to the top of the mountain”

Não negue as outras linhas de pensamento. Já vi isso dezenas, se não centena de vezes. O cara aprende Java e começa a descer o pau em .NET, aprende Kanban e começa a malhar em Scrum. Acontece todo o momento, muito, por medo dos profissionais. Muitos profissionais, por medo da contestação partem para o ataque e começam a detonar os outros métodos. Como eu sempre digo, não é porque você descobriu o martelo que agora tudo se tornou prego.

Assim meus amigos, nem preciso o quanto sabedoria pode vir de onde se menos espera e quanto isso é aplicável em nosso cotidiano, especialmente num mundo tão “dogmático” como esse de gestão ágil de projetos.

Vídeos Agile Tour 2013 – Maringá

logo Agile Tour 2013

Demorou mas saiu finalmente. Estive procrastinando isso pois estava tentando conseguir um tempo para editar, colocar uma vinheta, coisas assim.
Aconteceu que já estamos quase fazendo a edição desse ano e nada dos vídeos, então resolvi que vai como está. Portanto, material sem edição, bruto mesmo.
Perdoem as tremidas e imagens desfocadas, ainda não conhecia bem a câmera e nem sempre era eu filmando.
Continue reading

Achamos um bug, o que fazer?

green_bug
Esse é mais um daqueles posts que eu vou só defender uma idéia. Não tenho a menor intenção de proclamar, como sempre, o que é certo ou errado. Deixo para vocês decidirem, depois de estudar um pouco o assunto, não só através dessa postarem, mas através de outras fontes também.

A história começa com a implantação de uma metodologia ágil, seja ela qual for. Todo o ciclo de desenvolvimento ágil se baseia na entrega de valor, através da entrega contínua e adiantada de software funcionando a nossos amados clientes. Tudo na mais alta qualidade, como todo profissional deve fazer. Acontece que nem sempre tudo ocorre como queremos. Como somos seres humanos, passíveis de erros, esses refletem no nosso trabalho e por conseguinte, em nosso código-fonte.

Mas como fazer? Aliás, quando fazer? Devemos contar o esforço desse nosso retrabalho como parte da nossa velocidade, ou como não estamos entregando valor algum novo ao cliente, não poderíamos contabiliza-los?

Em uma das empresas com as quais trabalhei, a consultoria que lá prestou o serviço antes de mim, instruiu o time de desenvolvimento a não contar os bugs. Afinal, em princípio esse trabalho não representa uma entrega de valor ao cliente, certo? Se pensarmos bem, os bugs em geral são trabalhos que, como não foram bem feitos no passado, voltaram para atrapalhar o presente e portanto são responsabilidade do time de desenvolvimento. Confesso que por muito tempo eu concordei com essa visão monocromática da coisa. Mas um dia me mostraram a luz e hoje vou partilhar com vocês.

Quando estive estudando a fundo os métodos ágeis, em especial o Scrum, descobri que eles são mais do que métodos para gestionar projetos ou equipes. Eles são modelos para gestão do conhecimento. Eles fomentam a colaboração entre os membros do time, entre os times e principalmente entre time e cliente. Todos partem do princípio que ninguém sabe o todo de um projeto e ao assumir isso, constroem o conhecimento dando um passo de cada vez. Lindo não? Um passo de cada vez, assim como é difícil planejar anos a frente por que muita coisa pode acontecer em nossas vidas, nós como seres únicos, imagine muitos de nós interagindo e criando pensando num objetivo comum, o projeto em questão. Cada pessoa que se soma ao time é um acréscimo infinito de complexidade. São novas idéias, novas habilidades, mas também novos egos, novas dificuldades. Em um cenário dessa complexidade, imaginar que se possa planejar mais do que algumas poucas semanas é um sonho muito distante. Por isso planejamos de maneira iterativa e incremental.

Esclarecida a parte do planejamento, vamos falar um pouco sobre as métricas que regem o nosso trabalho. Sim, somos ágeis e usamos métricas. Porque? Simples, vivemos no mundo real, das corporações, no qual os gestores precisam de métricas para avaliar se estamos indo bem ou mal em determinado projeto. Mas quais métricas são justas para o time e a gestão? Quais métricas fazem sentido? A coisa toda em cima dos bugs é que diretamente eles não agregam valor ao produto. Afinal não adicionam nada de novo e é algo que em algum momento alguém deixou de fazer certo, portanto devemos fazer certo agora, algo como pagar pelo débito que existe no projeto. Mas nem sempre é assim. Muitas vezes, muitas vezes mesmo, as empresas de software tem baixa retenção de funcionários/colaboradores e isso obviamente envolve os desenvolvedores. Assim a equipe que hoje mantém um produto pode quase nem ter mais alguém que faça parte da equipe original. Portanto puni-los fazendo com que suas métricas sejam desmotivantes não é o caminho.

Mas então, o que fazer com os bugs?

Simples, corrija-os. Mas e as estimativas? E os esforços? Respondo perguntando: a correção de um bug demanda esforço? Vai gastar tempo dos seus desenvolvedores? Poxa meu filho, se isso não vai se resolver magicamente, se as pessoas terão que gastar seu tempo e trabalho para resolver aquilo então isso merece uma estimativa de esforço. Não caia na armadilha de confundir métrica de esforço com valor de negócio. Realmente um bug não acrescenta valor nenhum ao negócio, ao produto e isso é fato, mas certamente vai demandar esforço do seu time.

Portanto, ao encontrar um bug, coloque-o no topo do seu backlog e lembre-se, ele vai te custar tempo, portanto deve ter a sua medida, em story points, homens-hora, pontos de função, o que seja. Embora realmente não isso não vai aumentar em nada o valor do seu produto.