A Arte de Fazer o Dobro do Trabalho na Metade do Tempo sem Scrum

Fábula do Coelho e a Tartaruga

No começo era…

Trabalho há 2 anos em uma empresa que produz software para a área da educação publica. Acho bacana destacar que, quando iniciei minha missão como agente de mudanças na organização onde atuo, não tinha nenhum poder de decisão. O interessante é isso: o fato da iniciativa ter emergido de alguém sem poder total de decisão. Isso nos remete ao 3º princípio do Kanban: “encoraje atos de liderança em todos os níveis”.

Um dos maiores problemas em nosso ambiente era a dificuldade em alinhar os negócios com a TI, a divisão de tribos (técnica vs business), e a má comunicação entre silos de trabalho. Tudo isso contribuía para algumas relações tóxicas. Acredito que seja bom destacar isso antes de começar a contar toda a nossa jornada de mudança, pois você que está lendo esse artigo pode ter a capacidade de melhorar e influenciar positivamente todo o seu ambiente de trabalho independente do seu nível de poder dentro da organização.

Lembre-se:

“Não tente achar o que é o certo, mude o que está patentemente errado. Não mude o que não será fácil voltar atrás depois.“

A primeira metade da frase é uma referência a Nassim Nicholas Taleb em seu livro Antifragile. A segunda parte faz analogia a Russel Kirk a respeito de seu posicionamento político conservador.

E o que isso tem a ver com TI? Ou melhor, o que isso tem a ver com um grupo de pessoas tentando entregar valor de forma continua?

A Teoria das Restrições (ToC — Theory of Constraints) nos ensina que devemos atuar sempre no gargalo determinante “Não tente achar o que é o certo, mude o que está patentemente errado”, e quando estudamos o método Kanban aprendemos sobre o paradigma entre as duas formas de mudança: Evolução vs Revolução.

“Não mude o que não será fácil voltar atrás depois.”

A imagem acima mostra uma J curve of change, representando a capacidade em uma linha do tempo (quando digo capacidade estou me referindo a tudo, colaboração, conhecimento técnico e infraestrutura de uma organização). Podemos observar que perdemos maior capacidade quando a mudança é grande (kaikaku), porém com mudanças pequenas e progressivas conseguimos avançar com menos riscos. Inicialmente tentei utilizar a abordagem revolucionária, começamos a discutir sprints com timebox fechado, reuniões diárias, equipes auto-reguladas, definição de um líder para o time e até uma reunião para o review do produto, porém a resistência emocional foi imensamente grande, chegamos em um ponto que se você falasse sprint em voz alta poderia arranjar problemas com seus superiores.

O maior problema em tentar alavancar uma mudança baseada em ideologia é que normalmente você vai precisar dizer para as pessoas que o que elas pensam a respeito do trabalho é incorreto, isso envolve ego, vaidade, zona de conforto e se não houver um apoio top-down para que as mudanças aconteçam, sua vida vai se complicar.

Minha segunda abordagem foi evolucionária: optei por começar com o que já tínhamos em mãos. Em meio a toda essa resistência emocional que regia o ambiente, obtive a oportunidade de dar visibilidade ao processo da empresa ao representar graficamente todas as etapas e filas em uma ferramenta kanban colaborativa, esse foi o primeiro passo que contribuiu para engajar todos na mudança. Depois de viver essa experiencia no ambiente de trabalho passei a concordar com nosso colega David Anderson quando ele afirma:

Pessoas não resistem a mudanças, pessoas resistem a serem mudadas.

E realmente é igual a porta de banheiro, só abre por dentro…

Ta, mas cadê os números?

A primeira mudança evolutiva no kanban, após dar transparência ao fluxo, foi basicamente limitar a quantidade de trabalho em andamento (WiP — Work in Progress) em todo o quadro kanban, e isso causou um tremendo aumento na vazão (TH — Throughput) do sistema:

Cumulative Flow Diagram

Alguns já conhecem, mas para quem nunca viu esse é o CFD (Cumulative Flow Diagram), é um gráfico bastante simples e que mostra a quantidade de trabalho acumulado, ilustrando a saúde do fluxo do processo. No entanto, o CFD mapeia o sistema como um todo, sem fazer a separação da sua capacidade interna.

No eixo X temos o tempo, e no eixo Y temos o número de itens de trabalho, que podem ser: novas demandas, melhorias e bugs. Neste gráfico a camada azul demonstra o escopo (ou backlog) do projeto. As camadas verde, laranja, roxo e vermelho demonstram o trabalho em progresso (ou WiP). A camada amarela demonstra a vazão (Throughput) dentro da definição de ”Finalizado” do time. A seguir vou explicar com maiores detalhes as métricas utilizadas:

LT — Lead Time

Lead Time: Traçando uma linha horizontal entre o estado de “A Fazer” (Commitment point) até o estado de “Finalizado” é possível extrair o tempo médio aproximado que os itens levam para serem processados e entregues.

TH— Throughput

Throughput: É a taxa de saída, também chamada de Vazão. Não confunda o termo “Velocidade” com “Vazão”, apesar dos dois serem bastante correlatos, a velocidade é medida em pontos de história por unidade de tempo, enquanto vazão é o número de itens por unidade de tempo.

Durante esse processo de mudança coletou-se amostras antes de limitar o WiP no início de agosto e após limitá-lo até outubro:

Amostras coletadas em meu ambiente de trabalho
  • Amostra 1: É composta por dados do período de 01/06/2016 até 31/07/2016, nesse período o WiP ainda não era limitado, a única mudança evolutiva feita no kanban durante esse período foi a reorganização das filas para uma visão mais completa das suas etapas, dando mais transparência e a possibilidade de identificar gargalos e otimizar nosso fluxo.
  • Amostra 2: É composta por dados entre 01/08/16 até 30/09/16. Essa segunda amostra iniciou-se em agosto onde o WiP foi limitado.

Notamos que após limitar o WiP estabelecemos uma melhor cadência contínua de entrega nos cards, passamos á entregar mais e com maior frequência (e ainda diminuímos a demanda de falha, mas isso fica para outro post), isso se confirmou quando realizei uma regressão linear com os dados de vazão. Com o gráfico de regressão linear, é possível traçar uma linha de tendência, na qual possui uma equação parecida com f(x) = a + bx. Onde (a) é o ponto onde a equação cruza o eixo y, e (b) é o fator multiplicador que nos dá a inclinação da reta:

Após analisar as duas amostras e realizar a regressão linear de ambas concluímos que anteriormente entregávamos algo em torno de 3.15, após limitar o WiP no início de agosto a vazão dobrou subindo para algo em torno de 6.67, ou seja, obtivemos uma produtividade 2x maior e um tempo de resposta para novas demandas 3x menor, tudo isso sem nenhum custo adicional e com resultados em menos de 2 meses.

Magia negra isso?

Segundo a Lei de Little (Little’s Law) o Lead Time = WiP / Throughput, ou seja, restringindo o WiP obtemos um lead time menor. Porém isso aparenta ser apenas uma fenomenologia para esse evento, a Lei de Little é algo que foi provado por negação até hoje, mas não há duvidas de que limitar nosso WiP influenciou na redução o lead time. Acredito que inúmeros fatores contribuíram para essa diminuição, e o principal foi o aumento de colaboração no trabalho, em um sistema com capacidade limitada a colaboração é fomentada pois todos trabalham para evitar o estouro desse limite.

Entendam meu objetivo aqui. Consegui melhorar meu ambiente sem maiores problemas utilizando uma abordagem evolucionária, não estou dizendo que a abordagem ideológica (revolucionária) não funcione. Inúmeras empresas seguiram esse caminho e conseguiram atingir seus objetivos, mas é mais dificultoso a revolução funcionar. É tudo uma questão de risco e expectativa.

Concluo esse post com uma questão filosófica. Na sua opinião qual seria o ponto de alavancagem mais eficiente para mudanças, pessoas ou processos? E qual seria a abordagem mais ética?

yesterday you said tomorrow

Links muito úteis que me ajudaram nos estudos:


Agradecimentos:

Helal Ferrari Cabral - ferrari.work@gmail.com / helal.ferrari@taller.net.br

Rodrigo Yoshima -aspercom.com.br

Sem esses caras o post não teria acontecido.