A Arte de Fazer o Dobro do Trabalho na Metade do Tempo SEM Scrum
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.
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:
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:
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.
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:
- 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?
Links muito úteis que me ajudaram nos estudos:
- Kanban Avançado — Além de Visualizações e Limites
- Kanban: Aplicando TDD à melhoria contínua
- Kanban — O que é o WiP e por que limita-lo?
- Dizer sim ao Lean torna o resto irrelevante
- A Little’s Law, O Kanban e os Sistemas Complexos
- Outra base para a teoria contrária a relação Lei de Little x Limited WiP
- Why we love metrics? Cumulative flow diagrams
- Complexidade e Agile
- Série o Analista de Negócios: BVP na prática
- O que é BVP no desenvolvimento ágil?
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.
