[Resenha] Using Kanban to Turn Around Distressed Projects

O autor deste artigo, Steve Andrews, abordou um assunto que me interessa bastante: transição ágil. Neste post vou colocar os meus comentários sobre os pontos que achei interessante e vou terminar com uma observação que julgo importante, mas que aparentemente foi excluida pelo autor do artigo, depois que fiz o comentário no site.

Basicamente Steve mostra como trabalhou uma transição ágil em um cliente, que vivia o caos tradicional dos projetos de desenvolvimeto de software, que utilizam o BDUF (Big Design Up Front) no seu processo. Para iniciar essa transição, Steve optou pelo Kanban,.

Vamos agora aos trechos que resolvi ressaltar aqui.

... the best way to start removing the emotion from these types of situations is to work with the data and facts.

Essa afirmação me parece um ponto pacífico entre os especialistas em transição. Gerente, principalmente o tradicional, se preocupa com números e com os fatos lógicos que possam mudar esses números positivamente. Nada mais natural que começar uma transição desta forma.

...but initially it is not helpful to present the team with all the things they should have done differently...

Outro ponto importante que precisa ser observado em uma transição. Você dizer que "está tudo errado" vai gerar resistência emocional das pessoas que já estão neste contexto. Vocês podem não acreditar, mas alguns estão querendo fazer da forma certa e acham que estão no melhor caminho com as melhores opções disponíveis. Dizer que está tudo errado vai gerar reações desnecessárias e a atenção neste ponto pode significar sucesso ou fracasso. Interessante seria tentar a técnica sanduiche de feedback: começar com pontos positivos, mostrar onde pode melhorar e terminar com mais pontos positivos. Muito cuidado quando for falar dos pontos negativos.

...the only way we could start to do that was to create the environment for the development team to be able to focus on one problem at a time...

Outro ponto importante. Normalmente, em um ambiente onde o processo tradicional ainda vigora, as pessoas são solicitadas a fazer diversas coisas ao mesmo tempo e, ainda pior, o slack é duramente combatido. Chovendo no molhado, pois não vejo outra forma melhor de descrever, vou usar as mesmas analogias tão batidas entre os pensadores dos processos de desenvolvimento e perguntar: O que acontece quando a CPU do seu computador atinge 95% de capacidade? O que acontece quando o fluxo de carros em uma avenida atinge 95% da capacidade? Deixo essas perguntas para reflexão.

Estudos comprovam que, quando as pessoas focam em uma funcionalidade por vez e procuram tornar o processo mais fluidico, o time-to-market é reduzido drasticamente, pois o delay entre a mudança de uma tarefa para outra é um tipo de desperdício.

It is important to clarify that tests were developed on a work item by work item basis, not for a batch of work items at a time...

Sem muitos comentários adicionais, pois acredito que também seja ponto pacífico, entre os leitores desse espaço, a importância de se trabalhar em pequenos lotes, viabilizando os ciclos curtos de feedback.

...team had to keep asking themselves "now what was this supposed to do?" Even having to ask that question is wasteful

Este é um tipo de desperdício difícil de combater em empresas onde o modelo tradicional está enraizado. O motivo principal é que existem funcionários acostumados com a facilidade de ter uma babá e pessoas que gostam de ser babá. Existem empresas (grandes) com setores específico de babás. Com tanto conflito de interesses, fica difícil argumentar. Como fazer? Na minha opinião, é preciso estabelecer e consolidar os princípios de visualização do fluxo e pull system do Lean.

E finalmente, a passagem que motivou este post que, na minha opinião, foi a única imprecisão do artigo comantando o processo do Steve:

We also introduced work-in-process (WIP) limits to control the pace at which work items could work their way through the Kanban states. We observed that the analysts were not able to produce acceptance tests at a rate that kept pace with the developers. Since the developers could not keep working on new development tasks without violating the downstream WIP limits, the analysts became a bottleneck in the system.

Em uma transição ágil não é recomendado, em hipótese alguma, colocar a culpa sobre os ombros das pessoas. Na verdade, os princípios ágeis sugerem que devemos olhar para o processo e não fazermos uma "caça as bruxas". Em um transição, estamos tirando as pessoas da sua zona de conforto, talvez mudando papéis e fazendo estudarem coisas novas. Apesar de ser um contra-senso na nossa área, infelizmente, existem pessoas que fazem uma graduação, pós e certificação e acham que não precisam estudar mais nada, que já estão com todas as armas para enfrentarem o mundo corporativo. Amarga ilusão.

Mexendo nestes pontos geramos, naturalmente, resistencia emocional nestas pessoas. E quando as pessoas estão emocionalmente envolvidas em boicotar a transição, vemos as desculpas mais absurdas, que vejo sempre nas transições em que trabalho: "não tenho tempo para atualizar o quadro", "não tenho tempo para retrospectiva", "não tenho tempo para....".

Concluindo, em vez de chamar os analistas de gargalo, devemos, na minha opinião, mudar o foco para o processo de análise, pois normalmente, o processo é o problema e não as pessoas. Mudando o foco do problema, um sinal é lançado na cabeça dos envolvidos: "Qualquer analista que estivesse aqui, seria o gargalo, o problema não sou eu. O que podemos fazer para melhorar o nosso processo de análise?" Com este mindset, a pessoa pode até mudar a sua forma de trabalhar e se tornar mais eficiente, mas fará isso de forma inconsciente, e portanto tende a resistir menos.

O resultado disso é que em vez de gerarmos mais um ponto de resistencia, estamos trabalhando a pessoa psicologicamente e, na verdade, combatendo o que seria mais um problema.